REST: Lean JSON and XML from the same code

Generating JSON and XML with the same code is difficult. One can create the semantically richer XML and convert it to JSON, but JSON notations for XML like Badgerfish look quite ugly to JSON advocates.

The problem at the core is that XML is typed whereas JSON is not. Every node in XML needs a type – it’s name – for example <item><id>123</id><item>. JSON doesn’t need such a type, { id: 123 } is fine for an item. { item: {id: 123}} looks too verbose. Especially getting to the data in Javascript: var id = The same goes for accessing arrays with var id = items[0]; instead of var id = items[0].id;. The problem exists with other dynamic languages and data structures too, see Cobra vs. Mongoose for Ruby.

As I currently develop a REST based Jersey application in Java I needed a way to generate lean JSON and XML. Wouldn’t it be best to have one code for both? DRY. My previous solution for generation JSON worked fine. The $(...) method calls create a node tree with nodes and lists. With a JsonRenderer and the Visitor pattern I generate JSON from the node tree. The problem was that this Java code

creates nice JSON like { id: 123, items: [ ... ] }, but was unable to generate XML. As written above, the outer list has no type and a XmlRender therefor cannot render <shoppinglist><id>123</id>...</shoppinglist>.

The solution I thought about is to add type information to nodes which have no names.

The implementation uses a simple static method and a Type class.

The type is attached to the node and if the node has no name but a type, the XmlRender uses the type instead of the name. The JsonRender doesn’t use the type information and renders the same JSON as before. The piece of Java code now generates XML

and lean JSON where neither shoppinglist nor item has a type

Next thing is to automatically apply the right renderer, toXml and toJson from within Jersey. The content negotiation then choses the accepted format for the client. Attributes (Meta-Information?) are not solved yet and I’m not sure if they are needed, or how to nicely add meta information to the $(...) tree. There is some discussion in the context of markup builders and attributes on James blog.

Probably the code will be released as an open source RESTkit if someone is interested.

Thanks for listening.

Autowiring components to a message bus in Javascript

When writing AJAX and SOFEA/SOUI applications, it’s a best practice to use a client side message bus to integrate UI components. People recognized this as a best practice lately for GUI development with Swing. As a sidenote Werx was excellent for this but sadly is dead.

One of the ways to do message buses in Javascript is the OpenAjax Hub implementation or TIBCO PageBus.

Subscribing to messages on the bus is easy with the subscribe method:

When you have lots of those subscriptions though, they clutter up your code. Werx had the nice idea to autowire methods to messages and use the methods as message handlers. I thought I should do the same for Javascript and OpenAjax Hub.

Some magic happens in the connect method.

The same could be achieved with a map of message handlers which is easy with functions in Javascript whereas in Java it takes more boiler code. A solution with methods as messages handlers as seen above has the benefit though that the object can contain other helper methods and state, which a map of message handlers can not. Using autowired methods makes your message bus code cleaner and more readable.

Thanks for listening.

Problems with Jersey, REST, JSON and UTF-8 [Update]

UTF-8 is always a problem. Unbelievable. 2008 and we still haven’t fixed this. One of my current projects is a Javascript frontend with a REST backend. The backend stores to MySQL (a famous UTF-8 trouble maker) and creates JSON to REST calls. The problems starts with UTF-8 characters. Somewhere in the callchain – as always – characters don’t get correctly written. MySQL and the JDBC driver should work, the JSP page is UTF-8 (@page and meta-equiv), jQuery – which does the AJAX – and JS do know UTF-8 and Jersey should be UTF-8 too. But with some experiments now I’m quite sure that Jersey (JSR 311 REST framework) is to blame. I’m not sure how to specify UTF-8, this

doesn’t help. Funny, every major project with several frameworks along the call chain and several languages (JS, C, Java) makes UTF-8 problems somehow. I’m so fed up with this, it’s 2008.

Update: Jersey uses InputStreams for all encodings, especially StringProvider is relevant to me (se above). Does this work with Unicode?