4 ms·

I've found a good way to enforce schemas is do all testing against a Prism proxy. The proxy takes the OpenApi spec and basically maps the request going in/out i

I've found a good way to enforce schemas is do all testing against a Prism proxy. The proxy takes the OpenApi spec and basically maps the request going in/out into the model defined by the OpenApi spec. This means that if your request doesn't match the spec the test fails with a helpful error message. Similarly, because the OpenApi spec gives examples, frontend devs can use the proxy to mock requests and responses with literally 0 code written. This parallelizes development really well because you know everyone is building to the same spec. Running a bunch of debugs locally with the proxy does slow things up, but it's a trivial add to a containerized workflow. Highly recommended! Parallelized development, prevents breaking changes, and provides a canonical API model that's always up to date and enforced!

Zigurd 5y ago
OpenAPI is hugely useful in the way you describe, as well as making system capabilities understandable to non-coder project participants. Mocking responses enables non-coders, using tools like swagger.io, to see API documentation and easily interact with an API specs. This is vastly better than other attempts, like UML, to make system architecture visible outside the group of coders on a project. It is never too early to start making an OpenAPI spec. Technical product managers can even deliver parts of specs in this form. The tools are easy enough.
Scalestein 5y ago
This looks quite promising for some challenges I'm facing. Do you do anything towards having a central source of truth for API contracts? Like a single repo with the specs so that when a change is made everyone can develop against it?
- Raidion 5y ago
  Yep, that's exactly how it goes. Repo contains contracts. Tests pull the latest version from that repo, though you're able to locally override that version to pull in a "unofficial" version. Spec is created before any dev work begins. It might need changes when the work continues, no worries, the specs are versions and your team can decide on what stable versions are/aren't.

Zigurd 5y ago

OpenAPI is hugely useful in the way you describe, as well as making system capabilities understandable to non-coder project participants. Mocking responses enables non-coders, using tools like swagger.io, to see API documentation and easily interact with an API specs. This is vastly better than other attempts, like UML, to make system architecture visible outside the group of coders on a project. It is never too early to start making an OpenAPI spec. Technical product managers can even deliver parts of specs in this form. The tools are easy enough.

Scalestein 5y ago

This looks quite promising for some challenges I'm facing. Do you do anything towards having a central source of truth for API contracts? Like a single repo with the specs so that when a change is made everyone can develop against it?

Raidion 5y ago
Yep, that's exactly how it goes. Repo contains contracts. Tests pull the latest version from that repo, though you're able to locally override that version to pull in a "unofficial" version. Spec is created before any dev work begins. It might need changes when the work continues, no worries, the specs are versions and your team can decide on what stable versions are/aren't.