Why is this … my Swagger UI, generated from code not a contract? It describes my service, therefore it must be a Service Provider Contract. No?
This was a common theme for a few of our clients with mobile/web teams as consumers of enterprise services. Service providers generated contracts, and would sometimes create a contract in the API portal as well.
Service consumers would then read the contract from the API portal and consume the service. What the problem then? …
….the problem is that the red box i.e the Contract – is generated after the service is implemented and not vice-versa.
Why is this a problem then? It is a problem because the contract is forced upon the consumer and worse there are 2 versions of this document.
So what? Well as you can imagine, changes to the service implementation over time will generate the provider contract (red box), while consumers continue to read the out-of-sync contract.
so? A contract is an agreement between the two parties – consumer and provider. In the above use-case though, this is not the case.
- Generated Swagger UI is a documentation and not a contract
- A contract is a collaborative effort between Providers and Consumers
- A product (API Gateway) cannot solve this problem, it is cultural
- The above process will create 3 layers of responsibility – Service provider, Service consumer and middleware provider
- The 3 layers of responsibility makes it harder to test APIs
Side note: I believe this was a big problem with SOA – the “Enterprise Business Service (EBS)” was owned by the middleware team and “Application Business Services (ABS)” was owned by the services teams.
Collaborative contracts that help define what a service should do!
This contract is used by Consumers to build their client-code and more importantly the providers use the contract to build the service and test it!