There are a lot of problems with OpenAPI that are more pragmatic than ideological. “If we build to this spec, we get all this for free!” is the dream. It’s not the reality.
You’re a large tech company. Your front-end of engineers want to build with GraphQL. Your legacy API is 80% REST with some SOAP endpoints strewn about. Who gets saddled with the job of building to the OpenAPI spec and why? Where is it creating customer value? You introduce it and then what, what value did you actually unlock from your customer ecosystem? I’m not saying that it doesn’t create value — but which stakeholders can you explain that to and how long does it take to convince them?
On the other hand, if you start a new company, you’ll find that your API evolves organically. Locking yourself into a specification ahead of time is like writing all the unit and integration tests before a product ever gets in customer hands. Does anybody even want this? Are we even going to expose this API? What if we need to change it?
OpenAPI isn’t bad — quite the opposite, it’s fantastic. When we encounter an API that adheres to the OpenAPI spec it makes our lives a lot easier.
The problem is what I outlined above: for OpenAPI to permeate the market there has to be some sort incentive so powerful that it spontaneously aligns thousands of companies and millions of developers to accept it as the One True Specification. That’s just never going to happen.
So “standardization” can only come from something that creates an economic incentive so great that everybody agrees to it without hesitation. Which is a Herculean effort; it requires something like a product that’s never existed before, or an entirely new class of web developer. When you start thinking down that path you start seeing through our eyes at Autocode. I’m not saying we have the exact right answer today, but I’m saying this is how we think about the space.
You’re a large tech company. Your front-end of engineers want to build with GraphQL. Your legacy API is 80% REST with some SOAP endpoints strewn about. Who gets saddled with the job of building to the OpenAPI spec and why? Where is it creating customer value? You introduce it and then what, what value did you actually unlock from your customer ecosystem? I’m not saying that it doesn’t create value — but which stakeholders can you explain that to and how long does it take to convince them?
On the other hand, if you start a new company, you’ll find that your API evolves organically. Locking yourself into a specification ahead of time is like writing all the unit and integration tests before a product ever gets in customer hands. Does anybody even want this? Are we even going to expose this API? What if we need to change it?
OpenAPI isn’t bad — quite the opposite, it’s fantastic. When we encounter an API that adheres to the OpenAPI spec it makes our lives a lot easier.
The problem is what I outlined above: for OpenAPI to permeate the market there has to be some sort incentive so powerful that it spontaneously aligns thousands of companies and millions of developers to accept it as the One True Specification. That’s just never going to happen.
So “standardization” can only come from something that creates an economic incentive so great that everybody agrees to it without hesitation. Which is a Herculean effort; it requires something like a product that’s never existed before, or an entirely new class of web developer. When you start thinking down that path you start seeing through our eyes at Autocode. I’m not saying we have the exact right answer today, but I’m saying this is how we think about the space.