A lot of companies uses microservices, and have HTTP or async/event communication between them. It´s a common problem when server changes a thing, that something breaks on the client microservice. An we have tools like https://docs.pact.io/ that help on that, and pact is relying on OAS for some automation on contract/schema testing.
Problem
OpenAPI spec, AFAIK just describes the server part of http communications, and contract testing is all about checking the "match" between a client and a server, or a producer and a consumer. We researched and didn't find out a "contract/spec" that describes the client "behavior" or the way the client uses/sends data to the API. Pact is trying to do that with https://docs.pactflow.io/docs/workshops/bi-directional/ and using mock samples and other "client evidences" as way to extract this data to a file called PACT (their format).
Other thing to mention is that we are using the https://martinfowler.com/bliki/TolerantReader.html approach. So we don't export/generate http clients from open api spec. This approach reduces the "breaking change" problem, because the client does not need to know/use all fields/structure that the server produces.
Proposal/discussion
What if we had a "open spec" that describes, the client part of the communication? That could be very similar to the OpenAPI spec and could be used for contract/schema checks.
One of the challenges on that is how can we generate this spec. some options:
1)from mocked samples (wiremock)
2)recording runtime behavior on integration tests or even on production/sandbox enviroments
3) support some specific stacks, and parse that info from http client or any kind of "structured" code that tell us , how the request is going to be like. That could be done through static analysis or even evaluating some "runtime" http components.
But the main thing is not about how to get this files/spec, is about having a open spec for http clients.
If this is not the right place to start a discussion on that, please, we are open to all kind of suggestions.
lednubr
commented
2 years ago
Context
A lot of companies uses microservices, and have HTTP or async/event communication between them. It´s a common problem when server changes a thing, that something breaks on the client microservice. An we have tools like https://docs.pact.io/ that help on that, and pact is relying on OAS for some automation on contract/schema testing.
Problem
OpenAPI spec, AFAIK just describes the server part of http communications, and contract testing is all about checking the "match" between a client and a server, or a producer and a consumer. We researched and didn't find out a "contract/spec" that describes the client "behavior" or the way the client uses/sends data to the API. Pact is trying to do that with https://docs.pactflow.io/docs/workshops/bi-directional/ and using mock samples and other "client evidences" as way to extract this data to a file called PACT (their format).
Other thing to mention is that we are using the https://martinfowler.com/bliki/TolerantReader.html approach. So we don't export/generate http clients from open api spec. This approach reduces the "breaking change" problem, because the client does not need to know/use all fields/structure that the server produces.
Proposal/discussion
What if we had a "open spec" that describes, the client part of the communication? That could be very similar to the OpenAPI spec and could be used for contract/schema checks.
One of the challenges on that is how can we generate this spec. some options: 1)from mocked samples (wiremock) 2)recording runtime behavior on integration tests or even on production/sandbox enviroments 3) support some specific stacks, and parse that info from http client or any kind of "structured" code that tell us , how the request is going to be like. That could be done through static analysis or even evaluating some "runtime" http components.
But the main thing is not about how to get this files/spec, is about having a open spec for http clients.
If this is not the right place to start a discussion on that, please, we are open to all kind of suggestions.