This is more for client-server JSON schema validations, comes handy when different teams are writing client and server side code. Especially in startups where iterations are rapid.
This is more for client-server JSON schema validations, comes handy when different teams are writing client and server side code. Especially in startups where iterations are rapid.
From the way you've phrased your comment, I'm going to assume that the different teams are within the same start-up ... having a versioned, executable is even better when iterations are rapid if there are breaking changes. I've been in enough start-ups to know that things are skipped over to get a product out the door. I also know that the marketing and sales guys will say "we're already using a RESTful/JSON API for our back-end, let's open our API to third-parties to accelerate adoption of our SaaS". Ouch! (but I've been there)
I will admit that "back-filling" an OpenAPI specification for an existing service can be pretty daunting ... it's quite a bit easier if you start with the first MVP and iterate the ICD with each iteration of the client and server. Admittedly, we (software developers) still have issues versioning services. It's not so bad for incremental changes but breaking changes to a service where you have to support both older and newer clients is painful.