the blog for developers

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 = item.item.id. The same goes for accessing arrays with var id = items[0].item.id; 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

$(
  $("id", listId),
  $("items",
    ...
   )
);

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.

$( type("shoppinglist"),
  $("id", listId),
  $("items",
    ...
  )
);

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

public static Type type(String name) {
    return new Type(name);
}

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

<shoppinglist>
  <id>123</id>
  <items>
    <item><id>234</id><price></price><shop></shop>
      <description>Apple</description></item>
    <item><id>233</id><price></price><shop></shop>
      <description>Banana</description></item>
    </items>
</shoppinglist>

and lean JSON where neither shoppinglist nor item has a type

{ id: "123", items: [ { id: 234, price: "", shop: "", description: "Apple"}, { id: 233, price: "", shop: "", description: "Banana"} ]}

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.

You can leave a Reply here. Of course, you should follow me on twitter here.

You can share this post!
Do you want to tell others about this article? Use the social bookmark icons to submit this artice to the service of your choice. Thanks.

About the author: Stephan Schmidt has more than 15 years of internet technology experience and 10 years experience in agile. He was head of development, consultant and CTO and is a speaker, author and blog writer. He specializes in organizing and optimizing software development helping companies by increasing productivity with lean software development and agile methodologies. Want to know more? All views are only his own.
Leave a reply.

Comments

Stephan,
I thought Jersey automatically handled the return content type for you? For example if your REST Service method returned a jaxb POJO, then Jersey controlled what format to return it (json or xml) based on the produce MIME Type header; or something like that. I could have sworn I have seen something like that.

stephan

Hi James, well it does. But then I couldn’t control the JSON output. There are several discussions on the net on how to increase performance – one is to pack and reduce JSON output to inly the necessary data. And I wanted to have different representations for an item or list. Finally most often for SOFEA applications you do not have an 1:1 mapping for JSON data and Java objects, especially for aggregated data. Creating JAXB objects just for that data seems stupid.

Octavian NITA

Hi Stephan!

How about XStream? It’s a very nice library that supports both XML and JSON. You might want to take a look… http://xstream.codehaus.org/json-tutorial.html

Cheers!

stephan

Hallo Octavian:

I know XStream and quite like it. The problem with XStream is that as written in the post, I need a Java object for each representation with attributes and annotations, just to create an JSON representation of an object (and there are different representations, especially for aggregated data views)

definition texas holdem world pokerr tournament…

boasters frill pitiful….

Leave a Reply

What people wrote somewhere else:

Additional comments powered by BackType

Guide to CodeMonkeyism

Over the last 4 years I wrote many articles on this blog. To make it easier for you to find the relevant ones, I've organized them into topics.

Top 10

6 reasons why my VC funded startup did fail

Go Ahead: Next Generation Java Programming Style

Java Interview questions: Write a String Reverser

The dark side of NoSQL

7 Bad Signs not to Work for a Software Company or Startup

Is Java dead?

Scala vs. Clojure

Never, never, never use String in Java

No future for functional programming in 2008 – Scala, F# and Nu

Clojure vs Scala, Part 2

Java Developer

Is Java Dead?

Go Ahead: Next Generation Java Programming Style

Be careful with magical code

All variables in Java must be final

Never, never, never use String in Java

Bending Java: More readable code with methods that do nothing?

NoSQL Guy

NoSQL: The Dawn of Polyglot Persistence

The dark side of NoSQL

Essential storage tradeoff: Simple Reads vs. Simple Writes

Sharding destroys the goals of your relational database

The unholy legacy of databases

Startup/CTO

Development Dream Teams

6 reasons why my VC funded startup did fail

American vs. European style of Software Development

12 Things to Reduce Your Lead Time and Time to Market

The high cost of overhead when working in parallel

Essential storage tradeoff: Simple Reads vs. Simple Writes

Job Seeker

Another Good (Java) Interview Question

7 Bad Signs not to Work for a Software Company or Startup

Java Interview questions: Write a String Reverser (and use Recursion!)

Java Interview questions: Multiple Inheritance

As a Manager: What I value in developers

Top 10 Tips (+1) to Get a Pay Raise

Agilist

What Developers Need to Know About Agile

5 Practices Better to Change in Your Scrum Implementation

Scrum is not about engineering practices

ScrumMaster and ZenMaster: The joke of certification

What is Trans-Scrum?