Jetty and JSON

[EnterNoEscape]

I am starting to program the web interface for OpenDCT and I want to do this as well as possible so I am looking for advice; especially from our Jetty experienced members.

I feel like I should be using JSON for communications between Jetty and the browser since it should provide the best performance. Going between Java and JavaScript even when using libraries for JSON isn't feeling like the best approach due to how the program is designed. Most examples I see of JSON in action are akin to database entry and retrieval.

Sending JSON is trivial with a library like Jackson, but receiving seems a lot harder than it should be. I can't find a simple way to use the capabilities of the library to determine for example what capture device it's talking about since I would need to know that before I tell it to map the JSON to an object/objects. I'm assuming typically everything you need is normally in the JSON request and you're not suppose to resort to using GET with parameters to clarify what class the JSON is actually meant to update/create.

I can create an object that accepts the JSON request from the browser in a generic way, but then I still need to parse that to get everything going in the right direction. It has the feeling of being more time consuming than it should be. For the amount of time spent it would drive me to just use GET since it will be just as tedious, two less libraries and feel less hacky.

I really like to do things the right way if I can. Am I looking at this the wrong way?

[stuckless]

I'm not 100% sure what you are trying to do, but Jackson (or GSON) should serve your needs in terms of converting java objects to json and pasing JSON and turning it back into Java objects.

Maybe you can provide some more details on exactly what you are trying to do, and why you think that Jackson (or GSON) might not be the right fit.

[EnterNoEscape]

I was doing some research and it looks like Jackson is the most popular of the available parsers. GSON was shown to be very slow in comparison, but I suppose given the small amount of data to be passed back and forth it may not really matter if it's easier to work with.

I'll try to explain this a little better. Within OpenDCT, there are several specialized static classes. They are predominantly used to manage specific collections of objects. For example, ChannelManager is used to access, update and start offline scanning of channel lineups. Lets say the JavaScript requests a complete lineup. When the JSON is going out, the JavaScript side knows exactly what it's expecting, so there is no issue in that direction. It's when the JSON is coming back that I can't figure out how I would be able to look up the lineup again to update it. Maybe I'm missing something obvious.

What I really want to do in the case of Jackson is be able to apply incoming updates using ObjectMapper and ObjectReader, but I can't go straight to that step because I don't know what lineup I'm updating without already parsing the JSON. It's like a chicken and the egg problem. My thoughts are if I need to "manually" parse the JSON (using tokens for example) before I can even use ObjectMapper, most of the advantage is being lost.

In addition to this, there are other "managers" that are more complicated in that they actually have a mix of related objects that I could be intending to update. If I add information to the JSON coming in to be more specific about that kind of object it's trying to update, then I'm once again giving up the conveniences of ObjectMapper.

I'll take another look at GSON and see if it allows me to do this in a manner that doesn't feel frustrating. Thanks for any advice.

- Joe

[stuckless]

I think GSON or Jackson will both fit the bill here... and even is GSON is slow, you'll never notice it, not for what you are doing ("slow" in this sense means that gson might take 10ms whereas jackson might be 5ms)

Using json services is a combination of URL paths and json data.

So, lets say you are getting a list of lineups, you might have a url service like

GET /opendct/lineups

where on the server side, when you get a request for "lineups", you'll serialize your lineup data into json. You might do this directly, or you might decide to use a set of intermediate java POJOs to make life easier... but, Jackson and Gson both do well in serializing objects, and if you employed a good object model, you might not need the intermediate objects.

For each "lineup" that is sent back, you'll have and ID for that object. it might be the index in the array, if it's static, or some other mechanism to uniquely identify that lineup.

If you want a single lineup, you might have a service like

GET /opendct/lineup/LINEUP_ID
where LINEUP_ID is the uqiqueid of the lineup. On the server, when you see this request, you'll go to the manger, find the lineup, and use jackson/json to serialize it back.

later when you want to update a single lineup, you might post back the complete lineup changes (either the entire lineup, or just the fields that you want updated)
POST /opendct/lineup/LINEUP_ID
and then put the JSON object in the body of the post. LINEUP_ID is the unique id of the lineup being updated. On the server side, when you see a POST request for /lineup/ you'll pase the ID out of the URL request to find the ID to udpate. The body, you know will be of Java type OpenDCTLineup (or whatever your model class is), so now you can tell Gson/Jackson to map that JSON data to an OpenDCTLineup instance. It might allow you to map it to an existing instance, or create a new one. if it's the latter, then you'll have your merge your newly created object from the JSON data with the server's instance, or just replace the server's instance with your new one, whichever you prefer.

If you want to delete a lineup, you can use something like
DELETE /opendct/lineup/LINEUP_ID
and on the server when you see a DELETE request for a lineup, you'll find the lineup by id, and then delete it.

If are you creating a new lineup, you might do something like
PUT /opendct/lineup
And then put the entire json body in the PUT's body. On the server you can parse the json directly into you java object and then add it to your manager, which will assign it a unique id, and you can return the new ID in the repose, so that the client now knows what this object's ID should be.

So, in all cases when you are dealing with CRUD and fetch operations, you are using a combination to HTTP METHODS (GET, PUT, POST, DELETE) and url paths. It's the URL path that determine what object type you are dealing with.

The JSON data is normally put into the body of the requests, and the server knows what type the JSON data is, because of the URL that is came in on.

For replies, you'll take advantage of HTTP return codes. So if the request is good, you might return back HTTP 200 and the body would be the JSON reply (ie, a list, object, or some common message object type).

In the event of an error might employ various error code as they make sense...
404 if the lineup ID is not found
500 if the server encoundered some sort of unknown error
400 if the request could not be understood
503 if the opendct service is offline
etc

In the case of errors, return a json common error body response, so the the client can use both the http response code and the json error response in the body to respond to the error.

[EnterNoEscape]

You told me exactly what I needed to know. I wasn't sure if that was the right way to do it and I didn't want to do something that might be considered technically incorrect. Thank you for taking the time to explain it.