CODEWITHSUNDEEP
javaweb-services
Bagira
Bagira

Reputation: 2243

Webservice backward compatibility

I have a web service which takes as input an id return the object associated with that id.

Now I have a requirement that this web service will accept multiple id's and return multiple objects associated with those id's.

My concern here is that while incorporating the new changes I want to maintain the backward compatibility. Regarding the input I have solved the problem by accepting the "," separated string in the same field. So no concerns with backward compatibility with input.

But for output it would be a list of objects rather than a single object.

So my question is will returning list of objects instead of a single object break backward compatibility. I am aware that client will have to change that piece of code which was accepting the result from the service to accept a list.

What is the industry standard. Does this kind of change is considered as breaking backward compatibility.

Upvotes: 2

Views: 1083

Answers (2)

JBA
JBA

Reputation: 2844

First of all: Yes this is a change of the API that it is not backward compatible (e.g. clients need to change something because the structure of your response has changed from a single element to a list of elements).

Bigger companys (like 1k IT heads and above) i worked for used to have their WSDL/ XSDs versioned. Any structural change to the WSDL/ XSD has then beeing threated as an own, new version of the service itself so structural changes required an official release of the service to populate its new WSDL/ XSDs and the according changelog.

Both of the companys then deployed the new version as well as the old version of the component (e.g. the wsdl/xsd) under different endpoints with an end of live for the older version of about 6-12 months to guarantee backwards compability.

That way current clients did not have to change anything and our B2B partners could start to implement the new API.

So in your case you can provide backwards compability by having two versions in a similar way. I guess this could be seen as a lived industry standard.

Regardless you realy need that "big" solution (there comes many new troubles of complexity) and you like to have just 1 service with its 1 endpoint in production may better provide both of the variants as different operations. This way your API changes but has all of the old operations still available.

Assumptation (i just couldnt test it): The client should then not need to re-generate the stubs since the onces he used to use haven't changed.

So basicially i see those two possibilities to get backwards compability in general:

  • Have the service deployed/ running multiple times (e.g. multiple Endpoints like /myServiceV1, /myServiceV2). A new Version/ Release per API change

  • Have the service deployed/ running one times but have all of the old requests beeing part of that service unchanged.

Hope that helped a bit to make a decision ;)

Upvotes: 3

MadConan
MadConan

Reputation: 3767

If the client has to modify ANYTHING, then it isn't backward compatible. However, I fail to see why you would need to change the port/endpoint that currently exists. Instead, add another one to the service. Any client using the existing port/endpoint should not need to change anything.

Upvotes: 1

Related Questions