Let's say I have a REST API, that has the ability to provide field mask (i.e. the API can return M out of N attributes where M is a subset of N).

If a statically typed client (example: one that's written in Java) requests data from this API, is there a way to "gracefully" handle nullability issues.

If out of N fields, M are requested, then [N-M] fields are "null"...

  1. If the serializing class has all of the M fields; then N-M will be null. If this class is passed around to other logic, the code is going to be peppered with "null" checks in order to avoid NPEs. (Optional arg types only minorly alleviate the issue).

  2. The other option is to create different "data transfer objects(DTOs)" to handle various "common" field masks, and ensure that all attributes of these DTOs are non-null, so the calling code doesn't have to do null checks before every attribute access(example: I have 3 DTOs: SuperSimple, Simple, Detailed with preselected field masks). However; this can lead to DTO pollution in the code (potentially you could have 2^N such DTOs which is a drag on maintainability)

I'd appreciate your thoughts in form of a) design patterns b) frameworks features or c) standalone libs that target this problem


  • If you are allowed to effectively ask for a specific schema for the results of an api request, is it not the duty of the requesting code to map that into some intelligent representation locally? ie. give me ['First Name', 'Last Name', 'Age'] -> new UserAge(First + Last Name, Age);
    – Kain0_0
    Commented Dec 5, 2018 at 6:15
  • How about if I wanted (Name, Age) --> UserFirstNameAge(Name, Age)...etc..doesn't creating so many objects lead to DTO pollution in the code? From your example, I can potentially creat 2^3 = 8 such data transfer objects...
    – labheshr
    Commented Dec 5, 2018 at 6:38
  • The DTO would be a map/dictionary. The server would be responsible for populating that map from an internally representation based on the requested data fields. The client would be responsible for converting that map back to a representation. Take a look at JSON it is designed for this. A map is a synonym for an object. This works because that is all an object is, a list of key/value pairs where those values could be data or behaviour. Statically typed languages like to lock down what those property names are, and what they hold in advance. This is a hard mode of thinking to breakaway from.
    – Kain0_0
    Commented Dec 6, 2018 at 12:03

1 Answer 1


It really depends on your business logic requirements from the REST API response.

Regarding your proposed solutions:

  1. I'll advise you to have this checking code outside of the actual logic function, and have the logic function specify a contract/lambda that specify which fields are required for this function in order to pass it through to her. If you can, strive for a uniform representation that the contract can quickly verify upon.

  2. The DTOs will be hard to maintain as you noticed. Regarding the exponential blowup, solution 1 can deteriorate to an exponential number of contracts too (even on your current null checks) but I don't see how you can avoid it on the current information I'm given. (Worst case if you have a tailor made logic for every specific subset of the N)

It depends on more information to try to avoid this case-blowup, for instance if you have a logic that requires a certain field only you can have an iterator that moves on the REST response object (passing over null fields) and invoke dynamically the correct operator for-each.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.