Robert Buchanan, API Evangelist at Procter & Gamble
Um, I do feel that the OpenAPI tooling is general public, uh, or the industry is, is limited and we have not done a good job of investing in that tooling. Um, I think what it could offer the potential if, if we changed a bit of the open API specification, be open to, you know, new custom HTTP verbs, or even finding a way to bridge the gap between, you know, synchronous into a similar spec or into that fashion, I think ultimately what it could drive is. a lot of ways that we can build implementation tools to even generate some of the code in a more profound or robust way. I know there's currently generators and there's people that have done specs to our tools to generate from open API spec, but it's not something a company can quickly pick up conform to their core engineering principles or their core engineering libraries and whatnot. They have to restart the whole process over and over again. Um, I think the tooling in general, if we. If we had open API, uh, you know, more teams funding it or more company is really attaching to it. We could have a lot more tooling to, you know, really kick people off in the right direction sooner than later. Um, the biggest reason why I like it as a specification is it's one of the more popular ones. Rammel really didn't take off. Um, Smithy is kind of a good, but kind of out there as well from Amazon. But, um, we can use it as a talking point in conversations. Right? And like any contract, you need people to review it, you need people to read it, you need people to understand it. And it's at least a way to get it in front of folks, either in a configuration file as a source of truth in a GitHub, or by rendering it with a tool like Swagger UI or Redoc or RapiDoc. So it's a conversational piece to get the feedback loop started.
