RepreZen, creators of the RAPID-ML resource modeling language, has joined the Open API Initiative (OAI) to help move toward a standardized way of describing REST APIs. Additionally, the company is launching an editor which it believes to be the first on the market to work with version 3.0 of the Open API Specification (OAS) which is due for ratification by the OAI in July.
The Open API Initiative falls under the open governance of the Linux Foundation. The consortium looks to collaborate on a standardized way of describing REST APIs. This vendor neutral OAS originally evolved from the Swagger Specification.
RepreZen provides tools for API design, documentation and development using the current OAS 2.0 standard, and has just released experimental editing support for OAS 3.0 in RepreZen API Studio and the new open-source KaiZen OpenAPI Editor. OAS 3.0, planned for a final release in July, is an evolution of the spec, allowing API designers to describe hyperlinks, callbacks, rich message schemas, and reusable components.
CEO Ted Epstein believes RepreZen is the first available editor to work with OpenAPI 3.0 in its native YAML format.
RepreZen looks to offer an improved developer experience for OAS that gets you diving down to a deeper API contract and allows you to do it all from your local environment.
“Part of it is that, when you work with online API editors, you’re working in a browser environment that is completely separate from where you're coding,” Epstein told ProgrammableWeb.
However, he continued that, if you are working in an enterprise environment with on-premises version control, continuous integration and continuous delivery (CICD), the chances are these systems aren’t accessible from a cloud-based solution. Epstein said that people use RepreZen API Studios to access all of these resources.
Now, he said that “if you’re an Eclipse developer then you can have an even deeper level of integration.”
If you work in Eclipse, Epstein said you can simply install RepreZen API Studio as a plug-in to that integrated development environment (IDE). He said this is a really powerful level of integration for several reasons, including:
- No context switch between working on your API design and working on your code
- And if you’re doing truly API-first development, you can start with your spec written in OpenAPI, and then add your implementation code in the same environment.
Epstein told ProgrammableWeb about the role his tool, Eclipse and OAS all play in fulfilling what he calls your API contract or API Contract as Code. He said that Swagger Node Express and Swagger Inflector have run-time libraries that read the OpenAPI Specification and use that dynamically at runtime to dispatch method calls. It essentially does all the routing and validation at runtime, dynamically interpreting the OpenAPI Specification to drive some elements of the services.
“That is one way to do it, but not everyone wants to work with those frameworks,” Epstein said.
He said that many choose to use RepreZen in order to have code generation that’s available for many different languages and that works with many different frameworks.
Next, with RepreZen, you can use the API spec as part of your code base, that’s versioned with the rest of your implementation. You can generate code from the spec to whatever language and framework you're targeting — it becomes part of your automated build, helping to ensure that your code and your API spec are in sync.
Finally, it helps you maintain a strict separation between hand-written and auto-generated stub code.
“If the code generator is well written, it shouldn’t be hard to do this,” but sometimes that’s hard to maintain. Epstein maintained that “You have to maintain that strict separation, so you don’t have to modify generated code.”
“This is a generic blueprint for the API contract as code, using the Open API specification not just for documentation and not just for a one-time code generation template that gives you some scaffolding code,” Epstein said. “This is really fully integrating the API spec into your code.”
“When you’re working with the OpenAPI Specification, it’s definitely a higher level of abstraction. For every line of OpenAPI code you write, you get 20 lines of executable code.” Epstein continued that, with RepreZen, “You get this abstraction but you also get full visibility into your code.”