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 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,
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,
|Creation of APIs||APIs are created based on custom business logic and could be auto-generated during the application development process.||APIs are tuned and designed as per the needs of the external partners and third-party developers.|
|API Publishing, Sharing, and Discovery||Done on an Enterprise Developer Infrastructure/Network that is accessible to all other applications within the Enterprise.||Done on an External API Portal that is accessible to External Partners and third-party developers.|
|Purpose of API Consumption||Increase internal app development productivity, integrate applications within and across LoB resulting in streaming business operations.||Increase partner business opportunities, create new business models, and in some cases, direct consumer integration.|
|API Discovery||Need to be discovered on the same developer platform used by other internal applications willing to consume the APIs.||Need a public-facing portal to discover the APIs, explore them, and sample them.|
|API Subscription||May not need a stringent subscription plan to consume the APIs.||Need diverse subscription PLANs for API consumers to subscribe to and then consume based on SLAs, Payment Plans, etc.|
|API Policing||Need to make sure access of APIs are metered, rate-limited, and accessible based on Enterprise LoB needs and access rights.||Need fine-grained API control around security, access, rate limits, SLAs, and access limits based on Partner usage models and subscription PLANs.|
|API Access||May or may not need special tokens or keys to access the APIs. Mainly depends on the sensitive nature of data being exposed.||Need API Keys and security tokens to access the APIs.|
|API Invocations||API Invocations are in very large numbers as they are consumed by the Internal Applications.||Dependent on business requirements for access to external stakeholders. May be a much smaller number for Enterprise LoB Use Cases.|
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,
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 :
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.
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.
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.
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.
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.
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.
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,
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,
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  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.
Mayur Shah (email@example.com)
WaveMaker Passionate Technologist