WaveMaker now supports integration with OpenAPIs. If you have an OpenAPI definition document for your REST APIs, it can be easily integrated with a WaveMaker app. The OpenAPI Specification, originally known as the Swagger Specification, is a specification for machine-readable interface files for describing, producing, consuming, and visualizing RESTful web services.
Introduction to OpenAPIs
OpenAPI is a broadly adopted industry standard for describing modern APIs. The development of the specification is fostered by the OpenAPI initiative. It's important that you are clear with the difference between OpenApi and swagger.
The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for REST APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. A document (or set of documents) that defines or describes an API in called the OpenAPI definition document. An OpenAPI definition uses and conforms to the OpenAPI Specification. The specification can be found here.
As of release 10.4, WaveMaker supports OAS 2.0. Support for OAS 3.0 is being worked upon. We made the OpenAPI support more robust in 10.5. Keep an eye on this space for more updates.
Advantages of working with OpenAPIs
Since an OpenAPI definition document follows a standard OpenAPI specification, the document can be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.
WaveMaker extends this advantage to integrate REST endpoints in a Web/Mobile application. WaveMaker generates UI for Create, List, Update and Delete operations (CRUD) for REST APIs that confirm to OpenAPI specification. Integrating a REST endpoint with any of the 100+ UI widgets offered by WaveMaker is also simple and straightforward without writing a single line of code.
Since an OpenAPI document contains a number of APIs, WaveMaker identifies and groups a set of APIs under respective “entities”. For example, in an OpenAPI document, there can be multiple REST endpoints for an Employee entity. There could be respective endpoints to perform CRUD operations on this entity. While importing the OpenAPI document in WaveMaker, the platform performs a best guess algorithm to identify and map the endpoints against the respective CRUD operation. Once this is done, the app developer can make use of the Data widget combinations like Table/List with a Form and perform CRUD operations from the UI by simple drag and drop configuration without writing a single line of code.
This opens a wide range of possibilities for the platform to integrate with 3rd party REST APIs. To name a few:
- supporting various server side pagination/fragmentation/sorting techniques
- identifying relationships among various “entities”
- performing complex filter operations on an entity
- supporting various authentication/authorization mechanisms
We at WaveMaker are working to identify all such patterns and integrating it with the platform to provide a seamless experience. Keep an eye on this space for more updates.
Importing OpenAPI document in WaveMaker
If you already have an API document that is in accordance with OpenAPI spec 2.0, it can be imported into your WaveMaker app project and integrated with the UI widgets. Refer the following document on how to do so:
Importing REST APIs via OpenAPI/Swagger
Importing an existing WaveMaker app’s APIs into another app
The good news is all the APIs generated by a WaveMaker app follow OpenAPI 2.0 specification. Hence, a WaveMaker app's APIs are readily available for integration into another app. All you need to do is, take the OpenAPI/swagger json file from the existing app and import it into the other app where you want to consume the APIs. You don’t need to import each API individually anymore, which is a major time save.
Also, as mentioned above, the platform will identify “entities” from the OpenAPI document and group endpoints under these. So you can now perform the CRUD operations on a DB entity just the way you could do it through a DB CRUD (live) variable without creating individual Service Variables against each endpoint and writing custom logic to hook these operations. Here is a pictorial representation of the use case:
Generating OpenAPI document for existing APIs
If you chose a RAD platform like WaveMaker to build/modernize an app, chances are you already have a set of APIs to consume and plug the UI with. These endpoints can be on various back-end technologies, but the advantage with an OpenAPI document is that it is language agnostic.
Due to its open source nature, wide variety of frameworks support automatic generation of the OpenAPI document through code. Here is a list of language-specific tools you can use to generate OpenAPI document for your APIs.
The Microsoft world supports OpenAPI, too. ASP.NET developers can install the Swashbuckle package and easily generate a specification for their APIs.
The grape-swagger gem provides full OpenAPI support and works well with other gems, such as grape-entity. With the latter, it is possible to define models and use them in the specification as well as for input validation.
Goswagger is available for all the Go developers out there. It is a large package that is not limited to the use-case of self-documenting APIs but allows all kinds of work with Swagger and OpenAPI definitions in Go.
- OpenAPI initiative official space: https://www.openapis.org
- Swagger official space: https://swagger.io
- How to generate OpenAPI definition from code: https://www.blazemeter.com/blog/how-to-generate-openapi-definitions-from-code
- Importing REST APIs via OpenAPI/Swagger