Phil Sturgeon has been building APIs professionally since 2010. He’s worked as API/architectural consultant for all sorts of companies, from small startups to WeWork. He wrote about a lot of that in Build APIs You Won’t Hate, and grew a community around that into the largest API-related Slack channel on the internet. Now Phil builds API design tooling at Stoplight, helping with architecture and open-source.
API Description Documents (a.k.a “specifications”) can be used for all sorts of time and money saving things. Stop worrying about “keeping specs in sync with code” and use your specs as production code, speeding up development and reducing mismatch bugs.
API Description Documents (a.k.a “specifications”) can be used for all sorts of time and money saving things. At this point most developers are aware they can help with docs and have maybe played around with mocking, but they often have this concern about “keeping specs in sync with code”.
This talk walks through using API description documents for client-side validation (avoid validation hell by telling your clients how they should handle validation), server-side validation in the application (stop writing complex validation logic in your ORM model or some other awkward place), and validation in the API gateway (don’t even bother wasting application server resources with invalid requests).