We're using JaxRS & Jackson to send data to our client. Since the client is Javascript, we don't really need to send null values or empty arrays if there isn't a valid value for that property (which JaxRS does by default). Is there a way around this?
An example. JaxRS sends this:
{"prop1":[],"prop2":null,"prop3":"foo"}
where we could have gotten away with
{"prop3":"foo"}
There are multiple ways to achieve this, depending; annotation #JsonSerialize(include=JsonSerialize.Inclusion.NON_NULL) is one way. Or, since you also want to drop empty Lists, arrays, change NON_NULL to NON_EMPTY.
It is also possible to configure this as the default behavior; in Jackson 1.9:
mapper.setSerializationConfig(mapper.getSerializationConfig().withSerializationInclusion(
JsonSerialize.Inclusion.NON_EMPTY));
and in Jackson 2.0, bit simpler:
mapper.setSerializationInclusion(JsonSerialize.Inclusion.NON_EMPTY);
First of all dropping properties from your JSON could lead to errors or unclear code on the client side - the client side has to check if a given property exists before using it, if the property is missing there would be JavaScript error reported. Boring stuff.
Since HTTP communication is gzipped, the potential gains from removing properties does not seem significant (I can be wrong, obviously - I don't know your application). GET request can be effectively cached, so one more reason to avoid such optimalization.
You can customize serialization of Java objects to JSON as you need. See this question How can I customize serialization of a list of JAXB objects to JSON? for further explanation how to do this.
Related
This SO question explains how to ignore extra fields when deserializing JSON with Jackson
by using #JsonIgnoreProperties(ignoreUnknown=true), but I want to know when/why should I do this?
This overrides the default for Jackson, which is to throw an exception for unexpected fields. I assume if I should just use this default normally, but when/why would I want to design my system to be strict vs accept anything it can?
I guess this is more of a design philosophy question, so let me know if this is not the right place to ask.
The SO question itself has one of the scenarios as an answer to this question.
The problem is, the JSON objects might change and have new fields added while the application is published, but currently it will break even when a simple String field is added, which can safely be ignored.
There can be various scenarios where you need to ignore some of the json properties while serializing/deserializing JSON like If you are consuming json from a web service and just want few meaningful fields to be serialized. For example from an employee details json, you want just the employee first name and last name. This way you will avoid having a heavy employee object.
If the consumed service upgrades in future adding some fields, your code will continue to work.
Recently I was involved in a discussion regarding parsing response data from a REST API.
My point was that only client necessary data should be parsed from JSON object. In my opinion there's no obvious reason to clutter a client object with information not needed for it's use case.
Other opinion stated that we should parse the response 1:1 so that it reflects received data entirely and than create some intermediate object for client usage only with the sufficient properties. In this case I don't see any obvious reason how this approach would benefit anything.
Are there any best practices regarding this topic? What are the pros/cons regarding each solution?
When you say "parsed" form a JSON object, what do you mean? JSON is an object representation... Are you making another object that looks like the JSON object for some reason but isn't the one generated by JSON.parse()?
Assuming that is what you are doing, then you should make that new object as focused as possible, perhaps as a ViewModel. There would be little point in creating ANOTHER JavaScript object that looks just like the results of JSON.parse().
If this is not what you are trying to accomplish, then I likely need more details to comment.
My goal is to come up with a set of automated tests that will consume some services of an API and check if the compatibility is not broken (by mistake or on purpose).
My initial idea is to get the JSON results and deserialize against the DTOs used in the serialization. The reason is to avoid the manual generation of a schema that can get really big and difficult to maintain. The problem is that libraries like GSON are very robust and tend not to thrown exceptions when some problem happens in the deserialization (unless we write a custom deserializer, that again will take time and maintainance efforts).
Am I going in the right direction here? or is there another way to ensure API compatibility?
(Ideally, I would like to test not only JSON, but also XML responses from the same API.)
I have a horribly nested Entity Framework structure. A Schedule holds multiple defaults and multiple overrides. Each default/override has a reference back the schedule and a "Type". The Type has a reference back to any defaults or overrides it belongs to. It's messy, but I think it's probably the only way I can do what's required.
This data ends up in a browser in the form of Breeze entities. Before I can process these when saving them back at the server, I have to turn them back into JSON, which unsurprisingly trips the dreaded "Uncaught TypeError: Converting circular structure to JSON".
Now there are a number of perfectly good scripts for removing these circular structures. But all of them seem to replace the circular references with some sort of placeholder so they can be re-created as objects. But of course Entity Framework doesn't recognise these, so can't work with them.
I'm at a loss as to what to do at this point. Simply removing the circular references rather than replacing them doesn't seem to help as it can result in structures shorn of important data.
I've also tried changing my EF queries to only get back specifically the data required, but it insists on giving me absolutely everything, even though Lazy Loading is set to false and I have no .Include statements in my queries. But I feel this is solving the wrong problem, since we're bound to want to deal with complex data at some point.
Is there any other way round this?
EDIT: I've solved this temporarily by investigating the object and removing the circular properties by name. But I'd still like a generic solution if at all possible.
Seems like you are after serialization mode. find out serialization mode in properties in your designer screen and set it to unidirectional. this will solve your serialization issue.
Hope that helps!!!
Not sure I understand the question. You should never experience any kind of circularity issue, regardless of the complexity of your model, with a Breeze SaveChanges call. (Breeze internally unwraps all entities and any circularities before serializing). If you are seeing something different then this would be a bug. Is this the case?
I'm trying to find the most efficient way to send my Linq2Sql objects to my jQuery plugins via JSON, preferably without additional code for each class.
The EntitySets are the main issue as they cause not only recursion, but when recursion is ignored (using JSON.NET's ReferenceLoopHandling feature) a silly amount of data can be retrieved, when I only really need 1 or 2 levels. This gets really bad when you're talking about Users, Roles and Permissions as you get the User's Role, the User's Permissions, the Role's Permissions, and the Role's Users all up in your JSON before it hits recursion and stops. Compare this to what I actually want, which is just the RoleId.
My initial approach was to send a "simplified" version of the object, where I reflect the entity and set any EntitySets to null, but of course in the above example Roles gets set to null and so RoleId is null. Setting only the 2nd level properties to null kind of works but there's still too much data as the EntitySets that weren't killed (the first level ones) repopulate their associated tables when the JsonSerializer does its reflection and I still get all those Permission objects that I just don't need.
I definately don't want to get into the situation of creating a lightweight version of every class and implementing "From" and "To" style methods on them, as this is a lot of work and seems wasteful.
Another option is to put a JsonIgnoreAttribute on the relevant properties, but this is going to cause a nightmare scenario whenever classes need to be re-generated.
My current favourite solution which I like and hate at the same time is to put the classes into opt-in serialization mode, but because I can't add attributes to the real properties I'd have to create JSON-only properties in a partial class. Again, this seems wasteful but I think it's the best so far.
Any suggestions gratefully received!
Have you tried to set the Serialization Mode in the dbml file?
It's a standard property under code generation and when you set it to Unidirectional it won't generate all the additional levels of your table structure. I've used this with silverlight and WCF to send data because the data contracts don't allow for additional levels to be sent (silverlight is very limited on what you can and can't do).
Hope this helps!