Skip to main content
Category

Blog

OpenAPI Moonwalk 2024

By Announcement, Blog, News

An astronaut plants a flag with an OpenAPI logo on the moon.What comes next for the OpenAPI Specification? How will v4 improve on the success of OpenAPI v3? What can the spec help solve problems in the context of AI and LLMs?

As 2023 comes to a close, answers to these questions are beginning to take shape. With an aggressive goal of launching v4 “Moonwalk” by the end of 2024, it is going to be an exciting year.

Because there is so much work to be done, it was necessary to establish some guiding principles. After reviewing the major proposals and discussions of the last year, these are semantics, signatures, inclusion, organization, upgrading, and their order is important:

    1. 🌖 Semantics provide purpose. It is not sufficient to describe the mechanics of an API without also describing its semantics, whether the consumer is a human or an AI. Semantics join the what (… does this do?) and the why (… does this matter?) to the how (… does this work?).

      OpenAPI has helped people build better APIs faster, and the ecosystem of tooling continues to deliver more value year after year. What is new today in 2023 is the rise of a new kind of API consumer—generative AI. LLMs can process OpenAPI descriptions and then use that API to solve problems. With generative AI’s ability to understand natural language, OpenAPI can help bring the power of APIs to non-developers with a level of accessibility never seen before. To fully realize this potential, API producers should decorate their mechanical descriptions of HTTP requests with details that convey the meaning and purpose of those API operations. This, in turn, helps both people and LLMs to achieve better results.

      To say this another way, people have been using squishy, natural language to talk to each other for centuries, and we’ve used crunchy, programming languages to talk to machines for decades. LLMs bridge the squishy and the crunchy worlds, which means that a huge number of people can use APIs who could not before.

      Regardless of your opinion of generative AI, from over-hyped to world-changing, we can expect that many people will be using OpenAPI to drive AI-based API consumers. If OpenAPI does not step up to address the needs of that community, they will find alternatives.

    2. 🌒 Signature please! An API represents a set of functions, each of which describes a client-oriented purpose. A function is identifiable by its signature, which correlates to a set of HTTP interactions. Moonwalk places this concept at its center.

      Any HTTP API is always a means to some end. API consumers prefer to reuse existing functionality, and ideally they can learn about that functionality in terms that are most natural to them. That a PUT/PATCH/DELETE returns a 200 or a 204 is an implementation detail that pales in comparison to the function it performs for the client. Today there are limited ways to express the signature of an API function in OpenAPI. A pathItem can’t use query parameters to distinguish operations. There can only be one operation per HTTP method. These are artificial constraints on the signature of the API functions due to the lack of a formal definition of the unique signature. Past efforts in OpenAPI have focused on enabling developers to describe HTTP APIs. This reprioritizes them so that developers can use OpenAPI to define API functions with unique signatures that then map each signature to HTTP mechanics.

    1. 🌕 Inclusion needs a big tent: Moonwalk aspires to describe all HTTP-based APIs. While it remains neutral on the design aspects of HTTP APIs, it recognizes the importance of having different design styles and opinions.

      Moonwalk should be able to describe the HTTP APIs that developers may already have as well as to design the APIs they may want to build. It should be able to accurately map the signature of an API function to an actual instance of an HTTP request and response provided by the API. Moonwalk does prefer resource-oriented API styles due to their overwhelming popularity, but it should be possible to describe purely RPC APIs, even when those API signatures are distinguished via HTTP header values or request body values.

    1. 🌗 Organization through separation of concerns. For example, the changing shape of an API should move independently of API deployments. API deployments may be secured with different security schemes. API functions’ signatures should not be tightly coupled to content schema formats.

      To support the growing customer base with diverse needs, the feature count will undoubtedly grow, introducing more complexity. To counterbalance this, we will apply more rigor to the modularization of different aspects of the API description. We will strive to eliminate ambiguity where it currently exists and leverage existing standards to minimize unnecessary novelty. Our goal is to provide a better experience for API description consumers, authors and tooling providers.

    1. 🌑 Mechanical upgrading. An important principle of OpenAPI v3 was that it offered a direct upgrade path from v2. Moonwalk carries this forward, which means that it must again be possible to mechanically upgrade to Moonwalk from v3 (and by extension, v2).

Important open source projects like OpenAPI depend on contributions from many people. If you are as excited as we are about the ideas above or about the opportunity to leverage AI to help APIs be used by more people, then please get involved! A great way to start is to join our weekly calls on Thursdays (details), and anyone who wants to join is welcome!

 

Apidays Paris 2023 – with an OpenAPI Track – is Coming This December!

By Announcement, Blog, Events

The OpenAPI Specification is an integral part of software development and delivery of APIs. In 2023, we have been joining multiple API related conferences to connect directly with API users and enthusiasts around the world. Next up, the City of Light! Join us for the OpenAPI Initiative’s “OAI Track” at apidays Paris on December 6-7, 2023!

See our apidays Paris events page here.

What is the OAI Track?

The OAI Track is a specialized forum at apidays Paris hosted by the OpenAPI Initiative (OAI). This focused track aims to provide a platform for API practitioners to share and exchange valuable insights, experiences, and best practices related to OpenAPI. At Paris, we will have 3 different sessions with a total of 12 speakers! 

OAI Track Program Sessions

  • Current and Future Trends in API Specifications
  • Improving APIs and API Landscapes with API Descriptions
  • API Governance and Management with API Descriptions

Call for Contributions

The OAI Track is currently inviting contributions from interested individuals and organizations. If you have an experience or insight to share, we would be thrilled to include your voice in the discourse.

👉 Submit Your Proposal Here: https://apidays.typeform.com/to/ILJeAaV8?typeform-source=www.apidays.global#event_name=xxxxx 

👉 Register here: https://ticket.apidays.global/event/apidays-paris-2023/8a1f3904-e2be-4c69-a880-37d2ddf1027d/cart   

Why Should You Participate? 

  • Knowledge Sharing: Learn from industry experts and peers actively involved in API management and OpenAPI specifications.
  • Networking: Connect with a passionate community of API developers, architects, and business stakeholders.
  • Visibility: An opportunity to present your work and insights to a highly specialized and relevant audience.

Join Us, Join the Conversation!

Whether you’re an adept API craftsperson or an enterprise visionary keen on tapping into API magic, the OAI Track provides a fantastic platform to immerse and interact with the best of the API world.

Date: December 6-8, 2023

Venue: CNIT la Défense, Paris, France

Don’t miss out on this unique opportunity. Mark your calendars, and prepare to dive deep into the world of OpenAPI.

We hope to see you there!


For further updates and announcements, watch our apidays Paris page.

Join Us at apidays Australia 2023 for a Full-Day OAI Track

By Blog, Events

The OpenAPI Specification is an integral part of development and delivery of APIs. In 2023, we are joining multiple API related conferences to connect directly with API users and enthusiasts around the world. Join us for the OpenAPI Initiative’s “OAI Track” at apidays Australia in Melbourne on October 11th and 12th, 2023!

What is the OAI Track?

The OAI Track is a specialized forum hosted by the OpenAPI Initiative (OAI) as part of the larger apidays Australia conference. This focused track aims to provide a platform for API practitioners to share and exchange valuable insights, experiences, and best practices related to OpenAPI.

Key Focus Areas

  • User Stories: How are you or your organization using OpenAPI?
  • Tooling: Showcase tools you use or develop to enhance OpenAPI utilization.
  • Specification Extensions: Share any augmentations or adaptations you’ve made to the OpenAPI Specification that could benefit the wider API community.

Call for Contributions

The OAI Track is currently inviting contributions from interested individuals and organizations. If you have an experience or insight to share, we would be thrilled to include your voice in the discourse.

👉 Submit Your Proposal Here: https://apidays.typeform.com/to/ILJeAaV8?typeform-source=www.apidays.global#event_name=xxxxx

Why Should You Participate?

  • Knowledge Sharing: Learn from industry experts and peers actively involved in API management and OpenAPI specifications.
  • Networking: Connect with a passionate community of API developers, architects, and business stakeholders.
  • Visibility: An opportunity to present your work and insights to a highly specialized and relevant audience.

Get Inspired: Hear from apidays Founder

Still wondering if the OAI Track is the right place for you? Listen to Mehdi Medjaoui, the founder of apidays, discuss the essence and vision of the OAI Tracks at apidays events with Erik Wilde.

Join the Community!

apidays Australia is not just another tech event; it’s a rich learning ground and a launchpad for ideas to advance the API ecosystem. Whether you’re a seasoned API developer or a business leader looking to harness the power of APIs, the OAI Track offers an unparalleled opportunity to engage with the API community.

Save the Dates: October 11th and 12th, 2023

Location: Pullman Melbourne Albert Park, Melbourne, Australia

You can register here: https://ticket.apidays.global/event/apidays-australia-2023/f2d35972-9e81-401d-a29a-285fa1d00974/cart 

Don’t miss out on this unique opportunity. Submit your proposals here​​, mark your calendars, and prepare to dive deep into the world of OpenAPI.

We hope to see you there!
For further updates and announcements, watch our apidays Australia page.

Case Study: Using the OpenAPI Specification for Integrating SaaS Applications and Scaling Up to Hundreds of API Providers

By Blog

Guest blog post by Donald Atha, Software Architect, BetterCloud

One of the biggest challenges facing IT teams today is the increase in tedious and repetitive tasks driven by the explosive growth in SaaS applications over the last 10 years. Companies are using more and more SaaS products, which presents challenges when it comes to managing employee onboarding and offboarding, managing licenses and permissions, and resolving help desk tickets. At BetterCloud, we give IT teams the tools to reduce the amount of manual work on their plate with automations and configurable workflows. As the number of SaaS applications grows, our customers rely on our library of SaaS integrations to also grow.

Testing OpenAPI Generators for Rapid Integration

Recently the Innovation Team within BetterCloud, a team tasked with discovering and testing new capabilities that accelerate innovations, took on the challenge of prototyping a solution that would allow us to more rapidly integrate with various SaaS applications and scale that solution to onboard hundreds of API providers. The team agreed early on in order to reach the ambitions of the business, we would need to automate much of the process. The team also agreed that this would be possible because much of adding a new integration is the same and that the OpenAPI Specification would allow us to automate pieces of this by using existing community generators. 

To fully understand the problem, it helps to understand what it means to add an integration at Bettercloud and a bit about our product. BetterCloud’s workflow engine automates processes like employee onboarding by detecting when a new employee is hired and subsequently granting access to the various SaaS applications required for their role. This onboarding scenario is just one of many use cases we support. All these use cases invariably necessitate ingesting and storing data from the 3rd party provider and updating the provider’s state. For instance, in the onboarding use case, the ingestion process fetches employee data, detects a change in status, and triggers the onboarding workflow. This workflow calls the provider’s APIs to create accounts or grant access to shared resources for the employee—functionality we internally refer to as “actions.”

When embarking on adding a new integration, BetterCloud begins by validating that the provider has the necessary APIs to support our use cases. This crucial step sets the stage for efficiently accessing required data and assessing whether the provider’s APIs are compatible with our action use cases. The OpenAPI Specification provides a consolidated view of this information.

Reducing the Amount of Code Written by Using the OpenAPI Specification

Once the API is understood, the next phase is implementing the ingestion logic. This phase involves calling the provider’s APIs to fetch and store all necessary data within BetterCloud’s infrastructure. The team has explored two methods to coordinate this, both leveraging the OpenAPI Specification. The intent with both approaches is to reduce the amount of code that a developer must write when adding a new integration. The first involves code-generating an HTTP client in Java using the OpenAPI Java code generator, while the other approach uses extensions to markup the spec, enabling the configuration of the ingestion logic. This marked-up spec feeds into a general-purpose engine that implements the logic based on the extensions. This covers the ingestion of data from the APIs, but once acquired, it must be stored to serve our applications. 

BetterCloud utilizes a SQL database to store the entities we ingest. To create the schemas, the team employs the OpenAPI MySQL generator, Flyway, and Terraform. These tools facilitate the creation and configuration of a database for the new provider. The team was able to slightly modify the existing mustache templates of the MySQL generator in order to add our internal fields such as customer id. Since both the ingestion data models and the MySQL data schemas derive from the OpenAPI Specification’s entities, automation of this process becomes straightforward as the data models are aligned. With just an OpenAPI definition, we can generate a new database and its schemas at the click of a button in all of our environments!

Conclusion – Better Scaling the OpenAPI Specification, Better Value

We anticipate that this approach will allow us to bootstrap the ingestion portion of adding a new integration. By automating and code-genning common elements, the team can concentrate on the unique aspects of each new integration. Much like how we at BetterCloud automate workflows for IT teams to allow them to scale the impact of their work, the OpenAPI Specification has given us the tools to build our own automations that scale the value we can provide to our customers.

WireMock, Venture Funded Open Source API Mock Platform, Joins OpenAPI Initiative as New Member

By Announcement, Blog

The OpenAPI Initiative, the consortium of forward-looking industry experts focused on creating, evolving, and promoting the OpenAPI Specification (OAS), is announcing today that WireMock has joined as a new member. Welcome WireMock!

WireMock was created in 2011 and has been a popular open source tool for API mocking. Last year, project founders Tom Akehurst and Uri Maoz launched a company with the same name. They created a managed cloud service called WireMock Cloud, and in May 2023 announced a $6.5 million investment from Ridge Ventures, with participation from First Rays Venture Partners, Scribble Ventures and several unnamed investors.

Building a stable and predictable environment when creating APIs is crucial to the efficiency and success of developers. WireMock is a flexible and free open source platform that can be run as a standalone server, or in a hosted version via the WireMock Cloud managed service.

“We are thrilled to welcome WireMock as a member of the OpenAPI Initiative! Mocking APIs plays a crucial role in reducing development time and increasing productivity for developers. The open source community relies heavily on mocking tools in order to speed up development, better test for edge cases, and much more,” said Isabelle Mauny, OpenAPI Business Governing Board Chair. “It’s important for tools makers to implement the OpenAPI Specification and mocking APIs is one of the great benefits of using the OpenAPI Specification for your APIs.”

“OpenAPI is the key standard around which a rich ecosystem of tools and infrastructure is rapidly evolving. We believe that first-class OpenAPI support in WireMock will unlock a huge amount of productivity for both API developers and consumers,” said Tom Akerhust, the WireMock creator and the CTO of WireMock Inc.

“API-first development is at the core of both the WireMock open source project and WireMock Cloud, our developer productivity platform. Support for OpenAPI is central to our mission of enabling developers to simulate APIs across the entire application lifecycle”, said Oleg Nenashev, Community Builder and CNCF/CDF Ambassador, WireMock, “We believe that our vision and products are closely aligned with the OpenAPI Initiative. We’re pleased to join OAI as a member and work on expanding the OpenAPI ecosystem together”

Learn more in WireMock’s announcement blog post.

OpenAPI Resources

Want to become a member of the OpenAPI Initiative? Find more information here: https://www.openapis.org/membership/join 

To learn more about participating in the evolution of the OpenAPI Specification: https://www.openapis.org/participate/how-to-contribute

About the OpenAPI Initiative

The OpenAPI Initiative (OAI) was created by a consortium of forward-looking industry experts who recognize the immense value of standardizing on how APIs are described. As an open governance structure under the Linux Foundation, the OAI is focused on creating, evolving and promoting a vendor neutral description format. The OpenAPI Specification was originally based on the Swagger Specification, donated by SmartBear Software. To get involved with the OpenAPI Initiative, please visit https://www.openapis.org

About Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js and more are considered critical to the development of the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

About WireMock

WireMock is a popular open-source tool for API simulations (aka API mocking). It is used for integration testing of applications, especially via REST API. Started in 2011 as a Java library by Tom Akehurst, it now spans multiple programming languages and technology stacks. WireMock helps to create stable test and development environments, isolate code from flakey 3rd parties and simulate APIs that aren’t currently available. It can run as a test library, as a standalone server or via the WireMock Cloud service. With more than 300 contributors, 50+ integrations and 5+ million downloads a month, it is one of the most popular open source projects in its domain.

About WireMock, Inc. 

WireMock Inc. is building software to unlock developer productivity by enabling collaborative API design, mocking APIs and eliminating slowdowns caused by external dependencies. The company was started in 2022 by Tom Akehurst and Uri Maoz becoming its CEO and CTO. WireMock Cloud, the company’s flagship product, is built on top of the WireMock open source project stewarded by the company.

Recent WireMock News: What Our $6.5M Seed Round Means for WireMock and the WireMock Community

WebAssembly and Career Networking at Gluecon

By Blog

Guest Author: Tony Blank

Tony is an experienced software developer with an interest in web design, web marketing, customer integration, and software IT including networking, data center management, and sysadmin. He has attended many of the GlueCon events in the past years because of its highly curated content and focus on cutting-edge technology transforming the web, including API Standards. GlueCon was sponsored by the OpenAPI Initiative.

“Gluecon 2023 was an incredibly enjoyable conference. I extend my thanks to the OpenAPI Initiative for providing me with a complimentary ticket. If anyone is considering attending a future Gluecon and has any questions, please feel free to reach out.”

Email: me@tonyblank.com

Twitter: @thetonyblank

I can’t believe it’s been ten years since I first started attending GlueCon. This event has always been on my “must-attend conference list” because of its highly curated content, focusing on cutting-edge technology that is poised to transform the web. Throughout the years, I’ve had the opportunity to represent a few different companies at Gluecon leading community teams. However, this year is different. I was unfortunately laid off in March, and now I find myself in search of my next exciting challenge.

A conference like Gluecon is the perfect place for me to network and connect with innovative companies.

Back in 2013, when I first attended Gluecon, the conference was abuzz with discussions about web services and API standards. As a developer evangelist for Context.io, an email data API, I found Gluecon to be the ideal gathering to meet fellow developers and individuals keen on exploring new APIs.

This year, the main topic of conversation was WebAssembly.

For those unfamiliar with WebAssembly, it is a binary instruction format specifically designed for the web. Its purpose is to enable high-performance code execution within web browsers. These low-level languages execute on the web with near-native performance, revolutionizing the way applications are built.

It reminds me a little of when Docker was first released and it was apparent to everyone how useful containers are. In fact, Solomon Hykes, the co-founder of Docker, famously tweeted that if WASM had existed in 2008, Docker would never have been necessary (https://twitter.com/solomonstre/status/1111004913222324225).

The second time Solomon presented Docker publicly was 10 years ago at Gluecon, along with Jeff Lindsey. Jeff referred to Solomon’s quote during his talk at Gluecon titled “Futuristic Architectures: Session Backends and WebAssembly Components.” In his talk, Jeff brilliantly illustrated how standard WASM components will lead to innovative app architectures. It was a delight to catch up with Jeff, as the last time we crossed paths was in Paris at the dotScale conference back in 2014. He was showing dotScale Dokku, which began… as Jeff’s Docker demo for his Gluecon talk the previous year.

Another remarkable session was the fireside chat between Alex Williams, from The New Stack, and Matt Butcher, founder and CEO of Fermyon. Alex has been covering the most intriguing emerging technologies since his days at Programmable Web (RIP), and his conversation with Matt was no exception. Hearing about how the benefits of WASM, like cross-language compatibility and fast execution times, are being implemented by Fermyon in their new cloud offering was very exciting.

Not every talk at Gluecon was about WebAssembly. Any developer would have enjoyed Jason Harmon’s talk focused on internal API best practices. Treating APIs like products vs. a feature of a product leads to good developer experience, faster production cycles, and fewer headaches. Jason is currently the CTO of Stoplight.io, who went through the Techstars Cloud accelerator in 2015. Editor’s note: Jason was also a key figure in the early days of the OpenAPI Initiative!

It was fun bumping into Samy Fodil, who I met when his startup Sage Hero was in Techstars Cloud in 2016. Samy was at Gluecon this year talking about his current startup Taubyte and, yep, WebAssembly!

Gluecon always closes with some amazing keynotes. Unfortunately, I had to miss this year to get set up for Mile High Startups & Music, the monthly tech event I promote featuring Denver’s best local musicians. (Big shout out to Elastic for supporting both Gluecon and Mile High Startups & Music!)

I hope to see you there next year!

Tools That Support OpenAPI Specification

By Blog, News

Over the last 18 months we’ve been looking at how we can better capture data on the OpenAPI ecosystem with particular focus on tooling – what tool makers are doing, what versions of OpenAPI they support and so on. Tooling registries obviously already exist in the wild such as openapi.tools. The goal was not replicate the functionality of these registries, but to industrialize the data collection process using a mechanism that was eminently extensible and could be expanded with very limited modification.

Introducing our OpenAPI tooling registry. The registry exposes a “classic” UI based registry hosted at https://tools.openapis.org that uses data automatically sourced from existing registries and uplifted with data collected from (as a first cut) the Github API. This mechanism was proven by Mike Ralphson and used to publish https://apis.guru/awesome-openapi3/, and we’ve taken the approach and applied it to all Github projects we’re sourcing. We also provide the raw data as a means for users to “slice-and-dice” in ways they see fit or ways we haven’t thought of yet.

The sourcing and consolidation of the source data is wrapped by a build process written in Node.js that runs on Github Actions and collects new data on a daily basis. The data collection process itself is not wedded to a given data source. In our source repository we implemented the concept of “processors” that are tailored to a given source and then normalize the data to the registry format. As part of this process different tools are categorized using a Bayesian approach then attempts to put tools into the right “bucket”.

The repository as it stands is really just a first cut. There is more work to be done, with a list of issues currently focused on improving data quality, creating better categories and providing the data in a variety of formats. There is also an opportunity to use this data for outreach to tooling users, using it as an engagement tool to encourage them to both describe their needs and advance their tooling to the latest version of OpenAPI. There is also an opportunity to bring tooling data together across specification languages – GraphQL, Async API, JSON Schema et al – to elicit a more holistic view of the API ecosystem and look at how cross-specification tooling might be of benefit.
As always feedback is welcome. If you have any suggestions for improvement please raise them on the repository or get in touch if you’d like to talk in more detail about any aspect of the implementation.


OpenAPI Resources

To learn more about participating in the evolution of the OpenAPI Specification: https://www.openapis.org/participate/how-to-contribute

About the OpenAPI Initiative

The OpenAPI Initiative (OAI) was created by a consortium of forward-looking industry experts who recognize the immense value of standardizing on how APIs are described. As an open governance structure under the Linux Foundation, the OAI is focused on creating, evolving and promoting a vendor neutral description format. The OpenAPI Specification was originally based on the Swagger Specification, donated by SmartBear Software. To get involved with the OpenAPI Initiative, please visit https://www.openapis.org

About Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js and more are considered critical to the development of the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

Why the Largest Geospatial Organization in the World Uses the OpenAPI Specification

By Blog

The Open Geospatial Consortium (OGC) recently announced that OGC API – Tiles was adopted as an official OGC Standard. The OGC is a collective problem-solving community of experts from more than 500 businesses, government agencies, research organizations, and universities representing hundreds of thousands of geospatial professionals driven to make geospatial (location) information and services FAIR – Findable, Accessible, Interoperable, and Reusable.

The OGC API - Tiles Standard defines building blocks for creating Web APIs that support the retrieval of geospatial information as tiles. Different forms of geospatial information are supported, such as tiles of vector features (“vector tiles”), maps, imagery, and other types of geospatial information.

The new standard focuses on simple reusable REST API building blocks that can be described using the OpenAPI Specification.

Dr. Gobe Hobona, is the Director of Product Management, Standards at Open Geospatial Consortium (OGC). 

Dr. Hobona joined OGC Staff in 2017, having been an OGC member since 2004. As the Director of Product Management, he provides oversight of the development of OGC API Standards, managing releases, and product marketing.

Who uses the Open Geospatial Consortium and why? Can you give an example?

Standards by the Open Geospatial Consortium are used by hundreds of organizations to publish millions of datasets, as reported by GeoSeer.net. Many of the organizations are OGC Members that all actively participate in a consensus process that designs and publishes standard specifications which improve interoperability. A few of the domains that make use of OGC Standards are Aviation, Built Environment & 3D, Business Intelligence, Government & Spatial Data Infrastructure, Energy & Utilities, and many more. 

A great example of those standards being used would be in the aviation industry like EUROCONTROL, the European Air control agency and the Federal Aviation Administration (FAA) in the United States. Those teams publish a lot of their data using OGC Standards, specifically the Geography Markup Language (GML) which they have implemented in the Aeronautical Information Exchange Model (AIXM). Another example of the use of the standards is the OGC API – Features Standard which has been adopted as a Good Practice for implementing download services that are compliant with the European Union’s INSPIRE Directive, which positively affects hundreds of millions of EU citizens across the continent.

What’s new about the release of OGC API – Tiles? How will this be used? Who should use this?

We are really excited about it. The OGC API – Tiles Standard has been in the works for a number of years and now it is here. The OGC API defines building blocks for creating Web APIs that support the retrieval of geospatial information in tiles, basically little image chips that can be streamed with nearby chips to show a map. There are many great things about it, some special features include map tiles and vector tiles. Rather than the end user having to retrieve a large data set for the whole world, they can just retrieve that single tile. They can then use the identifier for that tile to collaborate with colleagues. Those in environmental sciences might retrieve a tile from other specialties and vice-versa. Now, instead of transferring terabytes of data across a network, it is just a subset. 

We have standardized models for Tile Matrices, we have a registry where various organizations can agree on a set of tiling schemes to use together. There have been significant efficiency and cost savings seen across the board. Transmitting complete datasets over a network can incur some charges, so transmitting only relevant subsets offers cost savings. Also, performance has improved. For tiles that do not change, it is now possible to provide a cached tile. We recently hosted a code sprint in Brussels where developers came together from across the globe, and within a short time they were able to implement this standard, and simply just used the implementations through various client applications. 

I’ll point out, all of that was made possible because the OGC API – Tiles Standard uses the OpenAPI Specification, which makes it attainable for web components to describe the capabilities for the resources, schemas, and so much more. In the previous generation of web service standards, it required developers to interpret the requirements of a standard. Now it is possible for some of that role to be done by the applications themselves. Apps can interpret what the API is intended to do. This takes away the burden from the developers and it leads to very happy developers!

What is the advantage of open source with spatial information?

Open standards by the OGC are used by both open source and proprietary software products; they do that to make Geospatial information more findable, accessible, interoperable, and reusable. One key thing about open standards and open source software is that they reduce the risk of vendor lock-in. With vendor lock-in, an organization gets tied to a single vendor and they must obtain products from that vendor. With open standards and open source software, it certainly reduces the risk of this and organizations do not have to buy from a single vendor. Furthermore, some common parts of commercial software come from open source to reduce the cost of developing some of that fundamental technology that can be shared; for example, the open source GDAL library is used by several commercial software products.

Why do you support the OpenAPI Specification? What are the main advantages?

The OpenAPI Specification makes it possible for developers to automatically create source code through code generators, by simply parsing an API definition document that complies with the OpenAPI Specification. In the past, most creation of source code required developers to manually read and interpret API definition documents, which led to human error and was certain to take longer to implement interfaces. Now, a lot of the interpretation is done by the application and then the human developer joins to codify the business logic. Moreover, using OpenAPI means that all of our APIs are defined in a consistent way so that the use of the APIs is predictable for all developers.

The efficiency gain for an organization is incredible. It is one of the key reasons why the OpenAPI Specification has been looked upon favorably by the OGC community.

OGC develops open standards, so everyone has the opportunity to provide some input to the standards. Other organizations do not have to wonder if there are some restrictions to access to the standards. But also, organizations can feed requirements in, as a community both the OGC and the Linux Foundation, which houses the OpenAPI Initiative and looks after the OpenAPI Specification, have done an excellent job of involving everyone across industry. There is a lot of feedback that is included or at least considered in the design of those standards. Everyone in the community has a chance to include input into those standards.

What is the best way to get involved in the OGC?

The OGC runs three member meetings a year, in different parts of the world, and with hundreds of participants. Now that travel restrictions are easing up, those meetings are now hybrid meetings with remote participants being supported. 

OGC working groups use those meetings to gather needs and specs. In between those meetings, there are a series of working group get-togethers. For anyone that is interested in participating, I would recommend going to the OGC website and have a look at the information about membership, there is also a list of working groups. We have domain working groups in defense, aviation, meteorology, and more. We also have other working groups that focus on specification, like OGC API – Tiles and OGC API – Features.  

The next OGC meeting will be from 20th to 24th February 2023, hosted by the European Space Agency in Frascati, Italy. That will be the first of three taking place in 2023, there will be another in June in Huntsville, Alabama, and another in September in Singapore.

I would also like to mention, the OGC runs several initiatives, we run innovation initiatives, where members can join in. These are run by the Collaborative Solutions and Innovations team in OGC, those initiatives are funded by the OGC membership, and they provide an opportunity for research and development. I encourage anyone interested to look at the OGC website and participate in these activities. 


OpenAPI Resources

To learn more about participating in the evolution of the OpenAPI Specification: https://www.openapis.org/participate/how-to-contribute

About the OpenAPI Initiative

The OpenAPI Initiative (OAI) was created by a consortium of forward-looking industry experts who recognize the immense value of standardizing on how APIs are described. As an open governance structure under the Linux Foundation, the OAI is focused on creating, evolving and promoting a vendor neutral description format. The OpenAPI Specification was originally based on the Swagger Specification, donated by SmartBear Software. To get involved with the OpenAPI Initiative, please visit https://www.openapis.org

About Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js and more are considered critical to the development of the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

Bump.sh, API Contract Management Platform, Joins the OpenAPI Initiative

By Blog

The OpenAPI Initiative, the consortium of forward-looking industry experts focused on evolving and implementing the OpenAPI Specification (OAS), is announcing that Bump.sh has joined as a new member. Welcome!

Bump.sh is an API contract management platform that helps document and tracks APIs: identifying what changes in APIs structure, and keeping developers up to date across an organization. Bump.sh acts as a single source of truth with information that remains up to date and changelogs.

The company has raised $4 million in funding led by Galion.exe and Bpifrance’s Digital Venture fund. 

“We believe schemas are the cornerstone of future-proof API development. As a vendor, it is our duty to contribute to and keep up to date with the latest specifications,” said Sébastien Charrier, CEO of Bump.sh. “Joining the OpenAPI community will help us better support our customers and contribute to the direction of OpenAPI Specification development.”

To learn more about Bump.sh, please visit: https://bump.sh/ 

Want to become a member of the OpenAPI Initiative? Find more information here: https://www.openapis.org/membership/join 

OpenAPI Resources

To learn more about participating in the evolution of the OpenAPI Specification: https://www.openapis.org/participate/how-to-contribute

●   Become a Member

●   OpenAPI Specification Twitter

●   OpenAPI Specification GitHub – Get started immediately!

●   Share your OpenAPI Spec v3 Implementations

About the OpenAPI Initiative

The OpenAPI Initiative (OAI) was created by a consortium of forward-looking industry experts who recognize the immense value of standardizing on how APIs are described. As an open governance structure under the Linux Foundation, the OAI is focused on creating, evolving and promoting a vendor neutral description format. The OpenAPI Specification was originally based on the Swagger Specification, donated by SmartBear Software. To get involved with the OpenAPI Initiative, please visit https://www.openapis.org

About Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js and more are considered critical to the development of the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.