I’m building a very thin Web interface for an internal application. The back end is built using Java, and I’ll be providing a Web service for use by the front end, which is built using PHP and JavaScript. The question is, if you were starting from scratch today, what would you use to glue the two together?
Options include:
- Providing a SOAP service, and implementing the SOAP client in PHP. (This option is only included for completeness, I’m not going to implement it this way.)
- Providing a REST Web service that returns XML and implementing the client in PHP.
- Providing a REST Web service that returns XML and implementing the client in JavaScript.
- Providing a REST Web service that returns XML and using JavaScript and PHP as the client where appropriate.
- Providing a REST Web service that returns JSON and implementing the client in JavaScript.
I have been leaning toward the JSON solution, but I’m curious to know what other people think.
February 10, 2010 at 11:36 am
I’d lean toward JSON too. Seems like the lowest-pain way to meet your immediate need, as well as being clean and adaptable to possible front-end changes down the road.
February 10, 2010 at 12:37 pm
JSON all the way. XML is heavy and finicky, laden with all sorts of complexity you don’t need if you’re writing the code at both ends of the conversation. Depending on how you’re building the Java side, you may want to look at flexjson (http://flexjson.sourceforge.net/) or json-simple (http://code.google.com/p/json-simple/) — both have served me well.
BTW, your comment system throws away the comment if you leave off one of the required fields. I had to re-type this…
February 10, 2010 at 1:03 pm
I’d lean towards JSON, although if XML, Atom & XHTML are the preferred flavors. You might look at Google’s JSONC as a “flavor” of JSON. The most important thing, I think, is to make sure the representation has solid link semantics. Using the HATEOS constraint of REST (leveraging the @rel of a link) turns out to be hugely useful for a system that may evolve on either the server, the client, or (most likely) both.
February 10, 2010 at 1:08 pm
The serialization libraries for Java for both XML and JSON are pretty good (assuming your objects are sane and without circular references), why not provide REST service so that it can return both XML and JSON? Then you can use JavaScript or PHP as appropriate on the client side without worrying about maintaining two output forms.
If you have to actually manage/massage the output, I’d lean towards XML unless I knew the client side was going to lean heavily towards JavaScript.
February 10, 2010 at 1:11 pm
I’d suggest a REST web service that returns JSON and implementing the client in PHP. That’s how many of Yahoo!’s applications work these days – the backend is a Java app, the frontend is PHP and JSON is used to pass data between the two.
I’m figuring out the WildlifeNearYou API at the moment, and I’ve decided to go with JSON only. It’s super-convenient to consume from every platform I care about. Add JSON-P callbacks and people can develop applications against it without needing to run any server-side code at all.
February 10, 2010 at 1:41 pm
As someone who did “REST” + Javscript + XML for our last large internal facing tool, I would recommend “REST” + Javascript + JSON. There is a little bit of extra conversion overhead each way with XML which you avoid if you use JSON.
Caveat: If the web service will also be consumed by other (possibly non-Javascript) clients, you may want to stay with XML since it’s more likely that a non-browser client has existing XML libraries (but not JSON libraries).
I put “REST” in quotes because our web services generally use the same URL path for all calls, the service being specified in the XML.
February 10, 2010 at 4:40 pm
I think JSON is a no brainer. It’s easiest for Javascript clients, and for other languages, if there’s not a JSON library, there ought to be, and in the worst case, it would be easy to hack one together.
February 10, 2010 at 9:02 pm
REST/JSON
No question.
I wouldn’t use any of the fancy JSON serialization formats either. In fact if I never hear the word “serialization” again it will be too soon as it encourages the extremely dubious idea that you can “send an object” from one computer to another, and usually ends up with unreadable JSON.
February 11, 2010 at 8:41 am
Option 6 – Providing a REST Web service that returns JSON and using JavaScript and PHP as the client where appropriate.
I think this mirrors what Simon Willison was suggesting and to my mind, sounds like a good path. You might be able to go all Javascript on the client. But if not, the flexibility is there.
February 11, 2010 at 4:23 pm
Oh, a PS: I might try out GWT as the client, if you’re doing Java on the backend.
My strong recommendation, though, is that you not use the GWT-RPC, not because it’s not good at what it does, but because you’ll never really have a standalone service that way.
By a HUGE COINCIDENCE I happen to have a cross-platform native-Java/GWT-Java JSON library I’ve been working on. (So far as I know there are no other JSON libraries that work in both GWT and regular Java-land, and very few that have JSON Objects implement Map and JSON Arrays implement List… as well as some other neat stuff.)
Release 1.0 in the next month, but I have, like, a 0.99 release right now I could send you if you’re interested.
GWT is a whole fun world of its own, but they’ve improved the environment greatly over the last year, so it’s a lot easier to get a project started. I like it a lot, although style-wise the widgets are pretty lacking. But there’s a lot to be said for getting to work in Java and being able to share some code between GWT and server-side Java.
February 11, 2010 at 5:05 pm
The front end of this thing is going to be a PHP/HTML thing — I have never looked at GWT. The back end app is already a Java/Spring MVC app, so I just wrote a dirt simple view renderer that uses Google’s GSON library to turn a wrapper object I created into a JSON response. I was impressed at how simple it was. Now I’m just wiring things.
February 11, 2010 at 6:17 pm
Cool.
I love JSON. Everything that was interesting about XML, without a bookshelf full of auxiliary technologies solving problems 90% of people will never have.
Just not having formal namespaces is huge. Want a namespace? Add keys prefixed with org.rc3. and be done with it.
February 11, 2010 at 9:58 pm
It’s hard to go back once you start using JSON as a REST transport. It’s just so simple, so compact, and easy to understand. And obviously dirt easy to make use of in JavaScript.