- Article: Consumer-Driven Contracts: A Service Evolution Pattern by Ian Robinson
- Recommended by Alex Grosse
- This article is not exactly cutting-edge — I arrived at similar conclusions years ago
- Many of the problems are related to XML and XSD and the excessive use of XSD validation that was popular in the SOA community 6–10 years ago
- The recommendations that clients implement only minimal validation — only validating fields that they actually care about — is a best-practice that I already fully advocate and strive to propagate
- Even more so: for years now I have advocated that schema validation occur only in the server, so that servers and clients can evolve independently — loose coupling.
- This requires that the people maintaining the schemas within the server be very thoughtful about backwards compatibility and about conforming to Postel’s law, both of which I’ve been an advocate for
- I also advocate for schemas that are permissive in the sense that they validate certain defined fields but also allow objects/documents/messages to contain any additional data — which is simply ignored
- The underlying spirit of all this permissiveness and loose coupling is quite similar to that of “duck typing” — not quite so far as to discourage validation as per the Python community, but so far as to basically say “Don’t worry about everything being dynamic! Most of the time, it just works. It won’t lead to as many errors as you fear. And the benefits in terms of flexibility are enormous.”
- The article can be boiled down to “Forget about defining, committing to, and conforming to, guarantees about the service. Instead, define, commit to, and conform to guarantees oriented around the needs of clients.
- Bottom line: it’s the clients’ needs that matter, not the services’.
- This seems to me to not always be true.
- I can see how this would have been a powerful and important proposition in the 2005-era of enterprise SOA.
- However since 2005 we have seen a massive rise of the development of the API (which is a service) as a product in its own right
- In that case, when an API is itself a product, then it is in fact necessary and important to make and conform to some promises about the service itself, rather than only on the needs of its consumers
- This is especially true in the case of the “One Size Fits All” or “Large Set Of Unknown Developers” strategies, wherein we really know very little about our consumers or their needs, and in fact the point of the service is to be very general so that a diverse and creative set of clients can be built on top of it.
- While these strategies have themselves recently begun to seem tired and costly, as pointed out in those linked articles, they do still have a place
There’s a lot of smart thinking in the article, but it’s way out of date. Massive changes to the landscape, both technical (e.g. JSON) and strategic (API as product) have limited its value outside of internal enterprise SOA design.