A web service I consume uses XSD to describe its API. Recently, they added a field to a reply message where no xsd:any had been, so when our schema validator tried to validate against the previous xsd, it failed. We considered this a backwards incompatibility and opened a ticket.

Their architect replied that we should validate our outgoing messages (requests), but not bother to validate replies. We should pick and choose the fields we want in the replies and ignore the rest. He also said that we should set our schema validator to ignore "new" fields and validate the rest.

If such a setting exists for some schema validators, then maybe this architect is not wrong, but on the other hand if my application breaks because a field I don't need to care about changed (or got created) doesn't that indicate a violation of the interface segregation principle? Is it really acceptable for me to validate the individual fields of the object piecemeal instead of expecting it to be all-or-nothing correct?

I realize that not validating incoming data from an external service has security implications as well, but in this question I'm trying to learn about the architectural principles more than the security aspects.

  • doesn't that indicate a violation of the interface segregation principle -- It depends on whether or not there actually is an interface, i.e. a formal specification. I'm not sure I buy the position "don't validate replies," though. – Robert Harvey Jun 3 '15 at 15:33
  • @RobertHarvey You don't regard an XSD as a formal specification of a data object's interface? – kojiro Jun 3 '15 at 15:33
  • Does their architect provide one? – Robert Harvey Jun 3 '15 at 15:34
  • @RobertHarvey The service provides various XSDs describing the schema for requests and replies. – kojiro Jun 3 '15 at 15:35
  • 2
    Then it sounds like the problem is they're not updating their XSD's properly. Just saying "don't bother validating" is not an excuse; they need to fix the problem. – Robert Harvey Jun 3 '15 at 15:35

Their architect replied that we should validate our outgoing messages (requests)...

They are not practicing what they preach. If they were, you'd be receiving messages valid to the XSD.

The problem is definitely on their side and they should fix it, but in the real world we often have to work around issues others create, so you may need to "not bother to validate replies" just to keep things going.

With Internet protocols in general, we try to generate standards compliant output while being tolerant of noncompliant input. I'm trying to find the RFC about HTML or HTTP (or whatever it was) that put it this way, but not much luck at this time. But the point is being tolerant on your side helps keep things going eventhough it feels dirty.

  • In general, the tolerance mandate applies to HTML, not XML. If you're going to validate XML with an XSD, there should be a reasonable expectation that the XML actually complies. – Robert Harvey Jun 3 '15 at 16:46
  • XHTML hasn't failed. I use it in almost all our projects - yes, served as application/xhtml+xml But then again, I like to know things are right. – Dan Armstrong Jun 3 '15 at 16:49
  • 3
    @DanArmstrong it sounds like you're talking about Postel's Law, which was directly quoted in an early TCP spec. – kojiro Jun 3 '15 at 16:53

If you're using the replies as input to your system, then you definitely should validate them. If you're just checking for success or failure, and possibly recording some returned IDs, then you probably don't need to validate, but I agree that you should make the web service guys fix their problem. They should have procedures in place to switch you to a new version of the service if they make a non-backwards-compatible change. And hopefully this will make them a little more careful about their schema design going forward!


I guess, if there is an XSD schema, you should be able to validate everything against it. Well, it is the purpose of itS existence ;)

So, I guess they just need to release a new version of their schema for you to update your software.

As for adding a new field into a reply... Well, if there was no schema, I would think that should not be considered a BC break. When you design an API consumer, you should be as agile as possible. Removing a field or changing its format should be a BC break for you. But adding a new one should not.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.