What do you guys do with JSON server side? In Java for example...

[Maximilian]

So I have AJAX requests that send JSON objects (as a string) to Java servlets, I can parse the strings back into a JSON object with googles gson. But then what? Should I keep using the JSON format or turn it into a native Java collection of some sort like a Map or whatever? Does it matter?

 

[Cogman]

So I have AJAX requests that send JSON objects (as a string) to Java servlets, I can parse the strings back into a JSON object with googles gson. But then what? Should I keep using the JSON format or turn it into a native Java collection of some sort like a Map or whatever? Does it matter?

Depends on how much of each end you are going to control. We have been bitten in the past because the object being serialized/deserialized has been updated but the client/server hasn't been updated to handle the extra fields. Jackson is the same way. You can kind of get around it but it is a little bit of a pain.

If you can guarantee that the client/server will stay in lock step with the version of the object they are using, then I would say just deserialize it into the object you desire. If, on the other hand, it is possible for different versions of the object to be serialized by the client and server, then the better approach is to deserialize into a map or write a custom deserializer that can handle version differences (about the same level of difficulty. With Jackson I believe you can get faster performance with a custom deserializer, with gson it is more of a wash).

If teams or outside clients that you don't control are going to be hitting this endpoint, I would suggest going the most flexible route possible. Anything less will cause you a lot of headaches in the future.

BTW, Jackson generally has better serialization/deserialization performance than GSON, and if you can get away with it, Protobufs will beat both of them (and it solves the version problem quite nicely). I have found serialization to be a largish bottle neck in my apps.

 

[Crusty]

In Ruby/Rails JSON gets deserialized into a standard Ruby Hash(really a Map) and can be processed in the same manner as a non-JSON HTTP request with a query string, as that also parses the query string into a standard Ruby Hash.

I find having a standard format of data(a Ruby Hash) presented to the entry point of your application makes it easier to reason through stuff like this, you don't need to worry about what kind of format the client wants to use so long as your HTTP request engine can parse the data into your standard format. This works well for TXT/HTML, JSON, XML and even CSV and makes a lot of sense in the context of Ruby on Rails since they provide all the parsing engines for the different content-types of a request.

 

[Ken g6]

PHP has good support built in: https://php.net/manual/en/ref.json.php

 

[purbeast0]

i've only used groovy to do this, and it just converts it to a map, making it very easy to use.

 

[veri745]

I just started a new project and we're using Dropwizard with Jackson to handle the JSON REST endpoints.

Works pretty slick.

 

[brianmanahan]

i use jackson to go from JSON to POJOs and back on my REST APIs, and it works perfectly