About Us | Login | Follow CITO Research:

The Strengths and Limits of Automatically Created APIs

The convergence of applications, websites, and databases on APIs is accelerating. By convergence I mean that APIs are becoming the common method for accessing information, in many cases by passing the application UIs, the web pages, and the query methods that were the initial way to access information and functionality.

The democratization of APIs is happening because increasingly APIs are created automatically. But in this wave of automatic API publishing, some important considerations about API security and management are being left behind. It is time to consider the responsibilities that should be taken into account when using automatically created APIs.

First of all, if you have any doubt that the use of automatically created APIs is on the rise, consider these examples:

  • Right now, with a simple declaration, any Force.com class can be automaticaly created as a REST endpoint. The plumbing for exposing and gaining access to that endpoint is provided as part of the platform. Other vendors such as Alteryx are taking the same approach.
  • Websites such as the European Union Patent office have mappings of every one of their pages to both URLs for browser access and URLs for REST APIs. Whenever a new page is published, both access methods are supported.
  • A startup call SlashDB offers the capability to automatically create an API to access the data in a SQL database. This API simplifies many of the details of SQL usage and makes it much easier for developers to get at the data using RESTful calls.

This trend toward automatically created APIs follows on the success of APIs that were created as gateways to popular consumer applications such as Twitter, Facebook, and Amazon as well as enterprise applications such as those provided by SAP, Oracle, NetSuite, and many other vendors. For both consumer and enterprise applications, use of these APIs have spurred many forms of innovation.

What is not recognized, however, about the success of these API programs is that they all came with some sort of API management layer, albeit often an incomplete one. The key to successful use of automatically created APIs is the recognition that the management layer must be supplemented with additional functionality to ensure that the API is used in a secure and orderly way. Here are a few considerations:

  • Most automatically created APIs inherit a security system from the application, website, or database they are accessing. While this is fine in some limited cases, most of the time the right point of management is not an individual API, but the application that may be using many different APIs. It is better to grant credentials to an application using API keys so that the use of resources by different applications can be tracked and managed.
  • Automatically created APIs lack the ability to monitor API usage by applications and perform tasks such as rate-limiting.
  • Automatically created APIs lack the ability to perform tasks such as routing APIs to different servers to allow for maintenance or to handle denial of service attacks.
  • Automatically created APIs lack the ability to perform transformations or to perform mappings between versions of APIs or to present simplified forms of APIs.

While automatically created APIs are going to be massive accelerators of progress, to avoid creating a mess down the road, it is important to pair them with mature API management capabilities. In this way, the creation and deployment of applications can be fully supported.