Our frontend JavaScript / Vue code makes uses of a number of "internal" REST endpoints, which are implemented in Java using Jersey/jax-rs.

We have an "informal" specification that lists the different REST operations, and describes the "beans" that are passed in/out. On the java side, we have different bean classes, and we use gson to turn the incoming JSON strings into Java objects.

Lately, I figured that our current setup on the Java side ignores bean fields that are unknown. So when the JS side provides a field that gson can't map to a Java bean class field, nothing happens.

On the one hand, this behavior seems convenient, for example it enables the JS side to do this:

  • calling a GET from the backend, receiving an instance of some X bean
  • adding other information to that object, to then send use it as Y bean on some PUT request

On the other hand, from the statically typed backend point of view, it just feels wrong to ignore incoming data.

My question: are there specific best practices or patterns that apply here? Are there good technical arguments to always allow "unknown" fields, or to always forbid them, and "fail" requests using unknown fields?


2 Answers 2


Ignoring unknown fields is a (very important) feature of keeping APIs backwards compatible. This is especially important when solutions are deployed at different times. E.g if frontend code has it's own pipeline and backend is in another or backend is split into microservices or even if some code is running where deployment it is impossible to control(in a browser where the user has a page loaded, you can't force them them to reload without inconvenience).

If you want to add a field that goes out to a browser and back it generelly goes something like:

  1. add new field to backend(and release)
  2. update frontend to use new fields(and release)
  3. update backend to require new field(and release)

This helps to minimize errors and enabling splitting code in multiple components.


VALIDATION of messages

In the old days, this was done with WSDL. Now, if you are using JSON, this is less well standardized, but adequately now.

Use JSON Schema

This way, when your clients send non-conforming messages, the developers will IMMEDIATLELY get feedback and not even checkin code that is broken (hopefully). Instead of debugging something weird, days or weeks after code is written.

  • Or rather beanvalidation.org ?
    – GhostCat
    Commented Aug 13, 2018 at 14:26
  • @GhostCat Maybe. I prefer technologies that are more widely used and not tied down to a particular system like java beans. But I'm not familiar with this tool and it maybe a good one. Commented Aug 13, 2018 at 14:33
  • That was exactly my thought ;-) ... the java side has to validate the incoming data anyway.
    – GhostCat
    Commented Aug 13, 2018 at 14:36

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.