Considering the Future of the OpenAPI Initiative
What do API developers need to do to be prepared for the continued influx of industry-specific API definitions through OpenAPI? Read on for some insight.
Join the DZone community and get the full member experience.Join For Free
I'm a member of the OpenAPI Initiative (OAI). I'm not very active on the governance or marketing, but I enjoy hanging out in the hallways of the Slack channel, and being part of the conversation. I'm pretty confident in the core group's ability to steer the direction of the specification, and leave my influence to be more about storytelling externally, and planting seeds in the minds of folks who are putting the API specification to use. I have a much different style to influencing the API space than many of the companies I share membership within the OAI- it is just my way.
I am working with more groups to help them craft, maintain, and evangelize around a specific OpenAPI definition, for use in a specific industry. The primary one on the table for me is the Human Services Data API (HSDA), which is an OpenAPI for helping cities, municipalities, and non-profit organizations that help deliver information around human services, speak a common language. This is just one example of industry-specific API definitions emerging. I am seeing OpenAPI emerge for PSD2 and FHIR, helping guide the conversation going on in the financial and healthcare sectors.
The OpenAPI as a top-level API specification standard is maturing, and is something that reached version 3.0, and once the services and tooling catch up, we'll see another boom in industry-specific API definitions emerge. This is when we are going to see the need to start harmonizing, standardizing, and merging many disparate standards into a single specification, or at least interoperable specifications. You see this happening right now with OpenAPI, API Blueprint, and RAML-they are all part of the OpenAPI Initiative (OAI). In the next five years, you will see this same thing begin occurring for other industry-specific APIs, and we'll eventually need governing bodies to help move forward these independent efforts, as well as feeding needs back up the supply chain to OpenAPI.
Maybe not right away, but eventually the OpenAPI will need to start thinking about how it establishes separate industry working groups dedicated to specific implementations of OpenAPI. I can see a healthcare, banking, education, transportation, messaging, and other specific industries emerge, needing a more stabilized spec, and formal group to help drive forward incarnations of the spec. It's taking me awhile to get the HSDA working group to be OpenAPI literate, but I'm already seeing the speed picking up, as different members learn to contribute to the HSDA OpenAPI, and understanding it is a central truth for code, documentation, testing, and for everything we are doing as part of the working group.
Just some food for thought. Like I said, we are a long way off from needing this, but I can already see it on the horizon. I'd just like to plant the seed with the OAI, as well as with folks out there who are pushing forward a specific OpenAPI within an industry. As you look to formalize what you are doing you might want to join the OAI, and participate in some of the conversation going on at the higher level. Maybe come to APIStrat in Portland this November, and bring your OPenAPI discussions with you. APIStrat has long been the place where we hammer out API definition conversations, so it makes sense to keep going, especially now that it is an official OpenAPI (OAI) conference. If you have any questions about what I'm doing with HSDA, and the future of industry-specific API definitions, feel free to reach out.
Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.