Best practice regarding interfaces between “typed” and untyped" languages?

Question

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?

Answer 1

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.

Answer 2

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.