rc3.org Rafe Colburn on software development (and other topics)

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.

Posted by Paul on 10 February 2010 @ 11am

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…

Posted by Dirk on 10 February 2010 @ 12pm

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.

Posted by Peter Keane on 10 February 2010 @ 1pm

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.

Posted by Bill Stilwell on 10 February 2010 @ 1pm

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.

Posted by Simon Willison on 10 February 2010 @ 1pm

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.

Posted by John on 10 February 2010 @ 1pm

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.

Posted by daveadams on 10 February 2010 @ 4pm

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.

Posted by Jacob Davies on 10 February 2010 @ 9pm

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.

Posted by Karl on 11 February 2010 @ 8am

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.

Posted by Jacob Davies on 11 February 2010 @ 4pm

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.

Posted by Rafe on 11 February 2010 @ 5pm

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.

Posted by Jacob Davies on 11 February 2010 @ 6pm

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.

Posted by Eric Mill on 11 February 2010 @ 9pm