For years, APIs and Services have been around in Enterprise Computing. In the good old middleware days, Service Oriented Architecture came into existence, and services were exposed using SOAP Web Service APIs. These APIs were mainly used to integrate applications to legacy systems and to one another.

With the advent of cloud, mobile, and the need for massive internal/external adoption of services, REST-based APIs have replaced SOAP Web services. REST APIs are HTTP-based, lighter, easier to understand, and integrate, and therefore, have become the de facto standard for creating enterprise APIs. Enterprise APIs can be internal APIs i.e. within or across LoB (Line of Business), or external APIs for partners and third-party developers.

In the past few years, enterprises, having learned from web-scale consumer APIs, realized that in order to create an ecosystem of applications around your API, it takes more than just creating an API and expecting consumers to use them. This is true for both internal and external APIs.

API Management

API management is the ability to document, publish, share, control, consume and monitor the consumption of APIs. All of this is done in a fashion that allows easy publishing and onboarding of developers using the APIs. So the question is:

If an enterprise is looking to publish internal and/or external APIs, is there a difference in managing them?

The majority of enterprises consume more internal APIs than external ones. API management is essential for both internal as well as external APIs as long as there is a need for,

• Providing easy means to manage the lifecycle of APIs (Create, Publish, Version, and Retire).
• Secure Access for protecting sensitive data that is being exposed.
• Differentiated Access while allowing the consumption of APIs among stakeholders.
• Easier onboarding of applications and developers that consume the APIs.
• Monitoring real-time access and usage trends of APIs and take actions as required by the business.

So how do you begin with API management? What we see is, depending on the maturity of the enterprise, the journey of API adoption can vary. Some enterprises with no APIs will start with internal APIs, get the ball rolling, work closely with internal stakeholders to fine-tune the APIs, and then roll it out for external consumption. On the other hand, mature enterprises may start directly with external adoption. Some may just roll out internal APIs depending on the business need.  Let’s take a look at differences in the requirements when it comes to publishing and consuming APIs,

External vs Internal APIs

Platforms that provide a unified approach to rolling out internal and/or external APIs can better facilitate enterprises willing to develop an ecosystem around their APIs. At WaveMaker, we aim to make the journey from internal to external API Publishing a seamless one. As mentioned in my earlier post, WaveMaker Studio, via API Designer feature, allows for publishing, sharing, and consuming APIs internal to the enterprise.  As these APIs become foolproof, and enterprises like to develop an ecosystem around it, they can use WaveMaker Gateway that allows for publishing, sharing, management, and consumption of APIs by external partners and third-party developers. WaveMaker Gateway provides full-fledged API management capabilities and is specifically designed, positioned, and priced for enterprises wanting to embrace and develop API Ecosystems around Partners and third-party developers. Click here for a demo of WaveMaker Gateway.

I have been talking a lot about APIs and their importance in the present day. You can find out the first 2 parts APIs series post 1 & API series post 2.  

This blog post is a continuation of the same series. I intend to take readers through an interesting read on the relationship between Low-code platforms and APIs.  

As discussed in the last post, there are 3 high-level actions for the API lifecycle,

1. API Publishing to create and deploy APIs
2. API Management to manage and monetize APIs
3. API Consumption  to discover and integrate with the APIs

Typically the actions - API Publishing & API Consumption get done in an app development platform and API Management gets done on an API Management platform.  

In this post, I will address how low-code platforms, as the torchbearers of modern app development tools, have taken the Application Driven Development (ADD)  as a mantra and has made life easier for developers around the world, including citizen developers.

A good low-code platform should be able to enable both API Publishing and consumption and have solid collaboration with an API Management platform as well.  Let's delve  into the details now :

Auto-generation of APIs

For some time now, Low-code platforms have been auto-generating the code based on visual development.  It’s time to do the same for the APIs.  Some of the most common APIs that can be auto-generated can include the services from DB, external services, custom-coded business logic, security services, etc.

For instance, it’s imperative that low-code platforms, at a minimum, should auto-generate CRUD APIs for the associated DB entities.  More advanced platforms can also APIfy the SQL queries and  DB stored procedures allowing total control for the users.

Other services like security and custom code business logic are also great candidates for APIfication.  For instance, if you have a custom coded in your CRM app a function to take return the list of all users from the EMEA zone, then that function should ideally be APIfied, automatically.

Automatic conversion of SOAP to REST

APIs these days are invariably REST-based.  But there are still big remnants, of legacy SOAP-based APIs, and modern low-code platforms would automatically create a REST API endpoint for the app.  This auto conversion is especially imperative in an enterprise setup, where legacy baggage is seen far too often.  The automatic availability of REST APIs is an important step in modernizing legacy apps.  

Easy consumption of APIs in an app

Out-of-the-box integrations and connectors are increasing making its presence in today's market. and a lot of app Development platforms focus on them. But often these platforms do not realize that there is always a custom API requirement for an app. Hence all kinds of integrations - both out of the box and custom should be treated equally.

Ease of design, testing, and sharing in APIs

Another pitfall in many low-code platforms is that they tend to focus a lot on API consumption through connectors and forget about API publishing aspects.  In a connected app world, it is imperative that your own app should have easy ways to create, design, and share APIs.  Inbuilt tools that can design your APIs (for eg, configure path parameters vs query parameters) with ease, test them (through an integrated testing sandbox), and then publish (private, public access) are important features in any other modern low-code platforms.  There should also be easy integration to publish these APIs into the enterprise API management platform so that it's instantly available to the API consumers within an enterprise.

APIs- a tad bit technical.

Modern REST APIs, though simplified, is still quite technical in nature.  There is still technology involved in understanding path versus query parameters, headers, auth headers, API key, etc.  Low-code platforms, which are positioned as app-building tools for business users and citizen developers still find it difficult to work directly with APIs.  A smart low-code platform abstracts these complexities and provides you with a nice UI-based connector to work on.  This is where the out-of-the-box connectors become really helpful.  But even APIs of your own app should also be abstracted the same way.  That is where a 2-pass development approach would be very helpful in terms of creating reusable UI components for the business user.

The above list looks very simplistic.  But a quick glance at various low-code platforms shows you the stark reality. In other words, API Driven Development is still just wishful thinking than a reality among low-code platforms.  This is one space WaveMaker scores far ahead of its competition.  This is one of the features that is going to make you ready for app building in the modern digital world.

Enterprise application delivery is evolving day by day and enterprises have discovered that traditional development methods do not address the needs of modern business. Many leaders continue to be in denial about the power of digital trends that are radically transforming the business landscape. But in the world of adapt or perish, enterprises have to make changes and take steps towards transforming their architecture to create provisions for future trends in application delivery.

The new normal

Let's take a look at six trends that have urged enterprises to take action. Each of these trends is not an independent phenomenon but a group of closely related phenomena that not only influence but also act as a catalyst for the others.

1. Mobility: In the last few years, not only have the number of mobile devices surpassed PCs, but users now turn to their mobile devices first. Ever since mobile apps entered the enterprise scene, they have ushered in new forms of collaboration, communication, and business efficiencies. The number of devices managed in the enterprise increased 72% from 2014 to 2015 and now, 3+ devices are used daily by an employee for work activities. With the diversity of screens and form factors exploding, enterprise mobility has become the key strategy for every business to empower and manage employee mobility in order to meet security, agility, and productivity demands.
   

2. Consumerization: The distinction between expectations for consumer and enterprise applications has rapidly narrowed due to the impact of consumer-originated technologies on enterprises. 90% of enterprises say that the use of a consumer or individual services used for work is pervasive today including Dropbox, Google, Skype, Linked In, Facebook, and other social networking sites. 49% of these sites are used with IT approval, and 41% are not. To achieve the greatest user adoption and long-term success, there is a conscious effort to move away from a purely utilitarian approach to one that strives to deliver an experience for that meets the same standards evident in consumer products.

3. Containerization: Perhaps the biggest story in the development and DevOps circles over the past couple of years has been the explosion of containers, with Docker driving the path toward developer and enterprise adoption. Docker’s express growth is already revolutionizing continuous delivery. The influence of containers continues to grow and it is beginning to move beyond mere optimization to transformation on the way IT builds and delivers applications. Several enterprises are looking at containers as an alternative to virtualization and cloud computing, at least for the need of long-tail business applications.

4. API Growth: With the dawn of cloud computing and the proliferation of apps, companies are exchanging data and services at an ever-growing rate. APIs can increase agility by de-coupling and exposing business processes. The past few years, however, have seen such explosive growth that the API space is evolving more rapidly than ever before. In 2015, as many as 40 APIs were being added per week to the Programmable Web directory, and the total number of APIs stood at around 15,000. The key thing to consider here is that these numbers are based on publicly available APIs and do not reflect any private or internal API growth at all, of which some estimate may even outnumber the public total. The future RESTful APIs will not only drive the exchange of data but also influence enterprise architecture.

5. Data Deluge: The amount of data being generated globally is growing at a rate of 40% per year. Add to that the complexity of an ever-connect world of the Internet of Things. Forecasts indicate that there will be 20.8 billion connected things (IoT) by 2020. As enterprises capture more data from more sources, they are bound to experience greater growth rates for both structured and unstructured data. Since data forms the crux of business applications, enterprises will have to prepare to manage data integration from disparate internal and external systems.

6. Microservices: Microservices are small, single-purpose applications that collaborate using APIs to deliver services. Even though microservices have been used for a while, the increasing popularity of cloud computing, containerization, and APIs have made microservices more reliable. In many organizations, developers are already employing microservices architecture whether management knows it or not. Early signs indicate this approach to code management and deployment is helping companies become more responsive to shifting customer demands. Microservices is poised to take the scalability and continuous delivery to the next level in the years to come

It is time to face this new dynamic and begin to plan for your organization’s digital transformation. You need a fresh perspective to give you and your team a powerful voice in setting business direction. In the age of the customer, tech
professionals must work with business executives to use technology to drive growth and delight customers. 

I would be glad to understand how your organization is planning to deal with these trends. Also, please add to these trends if you feel that I have missed out on anything.

Organizations across the globe rely on WaveMaker to navigate the new normal use. Our Rapid Application Development or RAD Platform is the most open, extensible, and flexible low-code platform that complements your existing enterprise application delivery. You can get started with a free, 30-day on-premise or online trial.

As we are all aware, in today's hyper-connected world of applications, it is not uncommon for any product, service, or application to have APIs. APIs (Application Programming Interface) has become the de-facto foundational technology for enterprise app development and more specifically for Web applications.

An API-Centric or API-Driven Web Application is a web application that basically executes most, if not, all of its functionality through API calls. In an API-Centric web application, the front-end communicates with the backend using just APIs.

There are a number of advantages of developing an API-centric web application, namely,

1. Easy consumption on multiple devices. RESTful APIs provide a lightweight integration model that significantly helps in creating mobile applications.
2. Business logic is well contained with individual APIs.
3. Ease of application development as the focus of application in on the front end-user interaction.
4. Forces Reuse, as APIs developed can be used by multiple applications on multiple form factors.
5. With the proliferation of APIs (Open, Cloud, SaaS), etc., developing applications becomes faster and easier.

In this post, we will see how developers can easily create API-Centric Web applications using WaveMaker Studio. Using Import functionality, a developer can use a wizard to import REST, SOAP APIs into the application development. Figure 1, shows how a REST API is imported in Studio,

REST APIs can be secured or non-secured. WaveMaker REST API Import Wizard allows for quick consumption of Secured as well as Non-Secured REST APIs. Secured APIs can be imported in 2 ways,

• Using Basic HTTP Authentication, passing in Username and Password. Enable the HTTP Authentication check box as shown in Figure 2, to import the API.
• Passing Security Tokens via HTTP Header properties. For example in order to authenticate via OAuth Security, Authorization: Bearer token is sent in the header to get back an OAuth access token. See Figure 3 that shows how the Authorization Token is passed to the API. Similarly other tokens, cookies can be used as required by the REST API.

API-Centric Applications also make it easier for external applications (Mobile as well as Web) to integrate into it easily. It does it by exposing REST APIs to the external world.

WaveMaker Studio soon [1] will have support for creating a Swagger 2.0 compliant API Specification file for the auto-generated REST APIs as part of the Application developed. See the previous post on API Designer that talks about Studio-Auto generating REST APIs. In the upcoming version, the API Designer will generate Swagger conformant REST API documentation. More about it in a later blog post. Figure 4 shows below the Swagger 2.0 document for the HR DB (Sample DB) REST APIs auto-generated by Studio.

This Swagger document can also be taken and used to publish the APIs for the external world using WaveMaker Gateway product.

Excited about developing API-Centric applications using Studio?  If so, log in to WaveMaker Online and create one. If you have any suggestions and feedback contact us.

Mayur Shah (mayur.shah@wavemaker.com)

WaveMaker Passionate Technologist