Home/ Questions/Q 3339078
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T00:27:03+00:00

I am in the process of designing a web interface that would support 2

  • 0

I am in the process of designing a web interface that would support 2 or more versions of a data schema. Data schema represented in JAVA could look like 

PersonV1 {
  String fname
}

PersonV2 {
  String fname
  String lname
  String email
}

In the future I am anticipating new versions being added. Is there any best practices for how this kind of UI would need to be built based on DRY principles etc.

A little bit of background on this. We have a product A and for every version of this product we might have a different schema. So per instance version I create a new schema. This schema is then made into a bunch of Java objects via jaxb and stored as a library. This process is repeated every time there is a new version of product A.

Product B will make use of the library and will fetch the xml from product A, since we know which version it is coming from we will be able to populate the correct objects and use them as the domain objects in a sense for the UI.

Thank you

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Depending on the type and diversity of your web interface clients, you can go two routes:

    1. Add schema version information to the path or in each object. Each client will then have to translate an object of a specific schema version into a form it can use. The safest approach for versions newer than that of the client software is probably to reject it completely.

    2. Have clients indicate their preferred/only accepted schema version in their requests to the server. It will then be up to the server to either translate from its current schema to the one the client is requesting, or fail with 400 indicating the requested schema cannot be supported.

    So, lets say you have a web client that only cares about fname. On receiving Person it will extract fname regardless of the schema version and carry on.

    Let’s say another web client needs the email address. It will accept a v2 person object, but inform the user that the server is not compatible if it returns a v1 person.

    Finally, lets assume v3 replaces fname and lname with name. In this case v2 can be transformed to v3 by appending fname and lname and perhaps v3 can be transformed to v1 by splitting name on space, but it would probably be hard to do something meaningful from v1 to v3.

    There will obviously be a lot of situations where either the client or server must give up and simply report the service or client is incompatible. But since you’re designing your service from the ground up with changes in mind, you will hopefully devote a lot more thought and caution to your schema changes.

    There are plenty of popular file format standards that struggle with this kind of problem. For example, there are multiple revisions of the Zip file format. Producers and consumers must each have a strategy for how to handle specific versions of the file format. The Java binary class format is another example.

    • 0