Search code examples
web-servicesbackwards-compatibilitynull

can adding a nillable field to a web service response break backwards compatibility?


I could implement my .Net web service API method in a way so it will set the new field to a value if a user is using the newer wsdl, and will set the field nil if the user is using the older wsdl.

Even then, is there a risk that the new field in the response could break some existing client app using an older wsdl. I know a client app could break if it gets a new field in the response that's set to a value (which the web service won't do), but could it break if it gets a new field in the response that's nil?


Solution

  • Yes, it can break the clients.

    Most webservices or clients validate the request or response before processing it. This is mostly done with an XML schema and the new field is not in the schema of your old clients;

    you will get errors like The element X in namespace Y has invalid child element Z.

    This is not a problem if the field is declared with minOccurs="0" in the new schema. This means an optional element which, if the value is null, simply does not appear in the XML instance.

    Nillable elements, even when their value is null, will always be included in the XML instance but marked with nil="true" which indicates that they are indeed null.

    Here is some extra info: Web services tip: Representations of null in XML Schema.