WaveMaker API Designer brings API-driven development to custom-built enterprise applications
Nov 20

WaveMaker API Designer brings API-driven development to custom-built enterprise applications

APIs have evolved from just being the building blocks of an application to become the core part of a business strategy of an enterprise.  Marc Andreessen’s words – “Software is eating the world” – is true for macro level business changes, but the real enabler for the software are the APIs working silently, behind the scenes to connect apps and devices together. Forrester calls this as “APIs become the digital glue” and lists it as a top technology trend to watch for 2014-16.  In the modern digital world, APIs have become the fulcrum for both business and the apps that drive the business.

Characteristics of an API

In API lifecycle there are 3 primary roles: API Publisher, who designs and deploys the API, API Gatekeeper, who manages and monetizes the API and API Consumer, who discovers and integrates with the APIs. Each of these API roles have multiple functions associated with them and those functions define the characteristics of the API. (See FIG-1)

FIG-1: API lifecycle roles and their functions
FIG-1: API lifecycle roles and their functions

WaveMaker Studio enables app developer to play the role of an API Publisher and API consumer, within the context of application being built. The role of API Gatekeeper is exercised in WaveMaker Gateway, a module that is planned to be integrated with WaveMaker Enterprise platform and is available in the upcoming releases.

What does API-driven App development mean in the context of RAD?

In traditional development approach, an API driven development methodology advocates that the front-end developers take control of the API design and build mocks, while the back-end developers use the API specs to concurrently implement tests and the back end business logic. This paradigm  is applied to Rapid App Development  in WaveMaker Studio, where the back-end services and front-end development is done concurrently based on the auto generated API contracts.  However RAD tools should additionally have features to design APIs for business needs, to configure APIs for access and finally to publish these APIs to be consumed.

API Designer in WaveMaker Studio 7.1,  provides a native integrated solution within the WaveMaker Studio to ease the process of designing, creating  and consuming APIs within the context of a WaveMaker application.  All the characteristics of an API as defined in the previous section will be addressed by the API designer and with ease. Lets jump in.

Say Hello to the new “API Designer” pull out in WaveMaker Studio 7.1

FIG-2: TBD API Explorer view
FIG-2: API Designer Pull Out

Currently WaveMaker generates REST APIs using Swagger based contracts for the following WaveMaker Studio back-end services

1. Database Service
2. Java Service
3. Web Service

Also WaveMaker generates standards based REST annotations for the above services, which are understood by API tools for generating API documentation.  Look out for a detailed blog post on all the auto generated API components in WaveMaker Studio.

Lets see how API Designer eases the process of using APIs as a publisher and consumer.

As an API Publisher: Design, Test & Publish APIs

Lets take a simple use case where the API publisher wants to publish an API to get a list of departments in the enterprise.  You can import the sample database provided with WaveMaker Studio to quickly test this.  Currently WaveMaker generates Data Access Objects (DAO) with CRUD based REST APIs for every table in the database schema.  WaveMaker also generates REST APIs for all the custom SQL queries that user creates.  The various end points corresponding to all the tables imported into the data model and their respective REST APIs are shown.  See FIG-3, which shows a few CRUD based REST APIs of the “Department” endpoint.

FIG-3: Database CRUD based REST apis
FIG-3: Database CRUD based REST APIs

You can further update the design of these auto-generated REST APIs by configuring their description, visibility, method types, parameter type etc.

For instance in FIG-3, user is configuring the visibility of the GET method of the “Department” end point.  The visibility options available to the user include the following:

°  Unavailable-  API is not visible even within the app
°  App-Only-  API is visible only inside the app
°  Private-  API visible to all the apps inside the Enterprise Developer Network(EDN) [1]
°  Public-  API visible external to the enterprise [1]

Java Services APIs have additional configuration options like the parameter types and method types.  Currently all the methods defined inside the Java service classes are automatically exposed as REST APIs that can be configured further.  For instance, if there is a Java service that is created for email services and receiveMail() is a method in that service, this method is automatically exposed as a REST API.  In our example, receiveMail() method has 3 parameters “emailId”, “count” and “unread” (to get only unread mails) and the expected REST API definition looks like this:

The above (FIG-4) given REST API definition can be easily configured using the API Designer as follows (see FIG-5):

custom built applications
FIG-5: REST API definition for Java Services

Once the REST APIs are defined successfully, the next step is to test the APIs instantly using the “Test” tab.  Lets refer back again to FIG-3 and test the GET method of the “Department” end point, as shown in FIG-6.

api designer swagger
FIG-6: Test your APIs instantly

Assuming that the API testing was successful, the next step is to publish the API [1].  Publishing the API would make it available for consumption in others apps, based on the visibility (see FIG-3) that was set earlier.  In WaveMaker, API publishing is done along with the 1-click deployment of the application as shown in FIG-7

wave apps api
FIG-7: Publish/Deploy API

As an API Consumer: Discover and integrate API into the app [1]

The integration of Enterprise Developer Network(EDN) with API Explorer inside the WaveMaker Studio, makes it really easy to discover APIs in other apps shared in the EDN and consume them.  You can easily browse through the shared APIs, select the API and then import using WaveMaker’s interactive web-service import infrastructure. For instance see FIG-8, where the DELETE method of the “Employee” end point in the HRMS app, shared in the EDN,  is tested and imported.

rest api designer
FIG-8: APIs imported from shared apps in EDN

EDN DevPortal [1]

Now that the API Designer feature in WaveMaker Studio has eased the functions associated with the API publisher and consumer, the next logical step is to enable the DevPortal integration with EDN.  DevPortal icon in the EDN home page (see FIG-9) will now take you to the DevPortal API Explorer where you can see all the apps in EDN and their respective APIs and it allows you to further discover, test and collaborate on these APIs.

api test console
FIG-9: DevPortal integration in EDN

WaveMaker is working to provide a complete end to end API driven app development approach through WaveMaker’s Enterprise Platform.  API Designer is another big step towards this goal.  Keep watching this space for a host of planned features, in future WaveMaker releases, which includes API deployment, consumption, 3rd party APIs integration and also WaveMaker Gateway, a new module in the WaveMaker Enterprise platform that will give a full-fledged API experience for the users.

Excited? Create your WaveMaker app now! If you have any suggestions or feedback, please mail us at feedback@wavemaker.com

Blog  Key

[1] Not available in WaveMaker 7.1. Planned for future releases.

Karthick Viswanathan
Product & Customer-Success Manager

About The Author

Karthick drives the Products and Marketing efforts for WaveMaker. He is happy to discuss in-depth, code-level details and can just as easily shift focus to business and go-to-market strategies. Prior to WaveMaker, Karthick has occupied various roles in the world of engineering and product management at PegaSystems, IBM and Oracle – giving him the ability to take decisions that consider both business and technology aspects.
We use cookies to provide you with a better experience. By using our website you agree to the use of cookies as described in our Privacy Policy. Continue