Application Programming Interfaces (APIs) are digital revolution
5 common APIs used today
There are hundreds of public and free to use APIs available online. There are even more private APIs designed by larger organisations to facilitate greater automation. The list grows daily as software developers continue to innovate and identify new opportunities in the market.
There are several APIs you use daily without ever realising. For example, your mobile phone uses the Google and Facebook APIs to create contact information automatically.
We’ve created a list of some of the more interesting APIs commonly used today and a few-up-and-comers who might shake things up in the near future:
1. Alexa Skill Management API (SMAPI)
SMAPI allows anyone to plug into Amazon’s servers and access its voice recognition database, the same used by their ALEXA virtual assistant technology.
Developers use SMAPI to create and test new skills for Alexa or enable voice recognition in appliances and software that do not already possess that capacity.
For example, using SMAPI, you could program a home computer oven to turn on and off via your smartwatch using only voice commands.
2. Travel API (Skyscanner)
Skyscanner is a travel search engine that scours the internet for travel and accommodation options, collecting them into one easily accessible place.
Skyscanner collects ticket prices, times, destinations and other relevant information, which the Travel API processes. You can access this API either directly through the Skyscanner website. Or, you can purchase the right to use the Travel API and plug it into any user interface you design, such as an app, website or widget.
3. Open European Article Number/Global Trade Item Number (EAN/GTIN) Database API
The Open EAN/GTIN database contains the barcode numbers and detailed information of over 320 million products worldwide.
The Open EAN/GTIN API lets users request this information from the database to display it on their websites. The API’s automation makes it easy to create new product listings on sales platforms like Amazon, eBay, Ocado and the like.
4. PredictionIO API
The PredictionIO API gives users access to an open-source machine learning server. This API enables developers to add automatic, predictive features to their products.
Both Spotify and Netflix use APIs similar to PredictionIO to automatically generate music playlists and TV show recommendations based on known user information.
5. Urban dictionary API
The Urban Dictionary API is an automatic service that looks up definitions of words and phrases when added to a web page.
This community-driven initiative crowdsources information to identify colloquialisms and slang on a web page. Users simply mouse over any detected words to learn their definitions in the English language.
The 3 main types of APIs
APIs are communication tools that devices use to exchange commands and data. Developers must instruct them how to read, translate and present the information they receive. These rules govern how we design APIs, how they operate and what we use them for. Today, there are three main categories of API architectures: REST, RPC and SOAP.
REST API
Representational state transfer (REST) is the most common approach to building APIs. REST relies on a client/server approach – much like your internet browser. This type of design separates the front and back ends of the API, i.e. the technical, finicky parts from the sleek, intuitive tools you use to interact with a web platform.
This separation allows considerable flexibility in development and implementation. A team of programmers can create the architecture and algorithms on which the API runs, then pass it on to another group who ‘plug it in’ to a user interface.
REST (sometimes called RESTful) APIs are limited because they only facilitate one-way communication. Clients send requests for information, and servers respond in a uniform and predictable way.
Because REST APIs are limited by the types of information they can send and receive, they’re easy to create and known to function reliably.
Example of a REST API
Flickr launched its RESTful API in 2004. This API allowed bloggers to take images from the Flickr site and quickly embed them into their social media feeds.
Flickr’s API used only these simple commands to achieve its purpose:
RPC API
Before REST became popular, programmers built most APIs using Remote Procedure Call (RPC) Architecture. Often called either XML-RPC or JSON-RPC because this type of API relies on these respective languages to translate data (much like REST relies on HTTP).
RPC APIs may be old tech, but we still use them today because they’re a good way of executing lots of complex interactions. They can be ‘taught’ to interact safely, so RPC APIs are often used to communicate with programs on other machines and edit sensitive information.
Users don’t often see examples of RPC APIs because they’re hidden behind the apps we use. However, they are still an important tool, as they’re well suited to executing commands (as opposed to fetching simple data).
Example of an RPC API
HR software relies on RPC APIs to collect different types of information from various sources, including communication tools (Slack, Gmail), scheduling tools, and payroll tools, and merge this information into a single data set that everyone can access quickly and easily.
领英推荐
For example, HR software uses RPC APIs to make sure changes made in one set of data are reflected in all others. This type of communication is something REST APIs cannot do.
SOAP API
Simple Object Access Protocol (SOAP) was designed to improve existing RPC APIs. It is, in fact, a sub-type of RPC API and not a new type of API in its own right.
SOAP simplifies the RPC communication protocol, using both XML and HTTPS in a very structured format. This allows developers to easily create new APIs by following a set approach to writing, sending, receiving and interpreting data.
SOAP is a highly structured and tightly controlled standard compared to REST APIs. However, this rigidity is its greatest tool, as any device which understands HTML or XML can also understand SOAP. In addition, SOAP can communicate across devices that use different operating systems, including web servers, mail servers, database servers and application servers.
Because of SOAP’s acceptance as a standard protocol by the World Wide Web Consortium (W3C), it also has advanced security features available via extensions. Many large enterprises use SOAP APIs for this reason.
Example of a SOAP API
Cloud storage services such as Amazon S3 make extensive use of SOAP APIs. However, you can find them used in any service which relies on sets of complex instructions that stretch beyond the scope of those functions provided by REST APIs.
While REST APIs are generally easier to design and implement, large organisations still use SOAP as an information transfer agent between in-house services.
Despite these advancements, fundamentals of business did not change significantly until recently when value creation was confined to real-world assets, commodities, and services that solve specific problem areas. Data was only a tool to increase efficiency. Now, with exponential improvements in computing power, memory, and bandwidth, it is easily possible to collect, store, and analyze data at unimaginable scales. This has empowered businesses to continuously analyze consumer preferences in real-time and determine their sales/distribution strategy. Therefore, organizations are no longer looking at data as only a means for improving operational excellence. Instead, managing data has become the core that drives business.
Consuming and exposing rich data via managed APIs has become the most potent tool to realize this vision and turn it into an opportunity to generate revenue.
APIs are Not Just the Engineering Tools that Enable Back Office
APIs were originally intended to establish formal contracts to exchange structured information between distinct application components from multiple vendors (for example, between an operating system and application software). With the advent of Service-oriented Architectures (SOA) and data standards (XML, JSON, etc.), APIs emerged as a robust and efficient method to transport data across multiple application landscapes transcending technical and organizational boundaries. IT departments capitalized on this and created highly interoperable business applications that could seamlessly communicate via webservices.
But today, the term API has traversed beyond this limited connotation of being just another mechanism for software and API developers to design systems. It has now become one of the main pillars on which the core line of business operates across industries like banking, insurance, manufacturing, travel, retail, etc. Following are some examples that showcase how businesses are utilizing APIs (usually coupled with an omnichannel strategy) for enhanced customer experience:
Exposing APIs as Monetizable Services
Advances in technology and processes enable seamless ways to expose APIs for revenue generation, provided they are backed by suitable API integration services. Just like any other evolutionary phenomenon, leveraging APIs as a commercial revenue generating tool is not a sudden development. It’s a result of step-by-step improvements at each level of system engineering. Following are some of the key enablers that have shaped the ecosystem –
Infrastructure and Firmware
Unless the data from enterprise legacy systems is deployed on infrastructure that enables efficient and frictionless management of resources, it’s bound to be a risky exercise (due to unpredictable capital expenditure) to expose it as APIs to external partners. Thanks to the advancements in virtualization of hardware/firmware (hypervisors, containers), organizations can now transform their legacy data centers into ‘easy-to-maintain’ private clouds where virtual machines can be spawned and governed centrally.?
Middleware Technologies and Tools
In addition to the modern virtualized data centers, mature mechanisms for accessing data from disparate systems is critical for API enablement. Developments in the middleware technologies like messaging (e.g. Message Oriented Middleware (MOMs) like Message Queues (MQs), Enterprise Service Bus (ESB) etc.), remoting (e.g. Remote Procedure Call (RPC), Object Request Brokers (ORBs), HTTP invokers etc.), and governance (e.g. reverse proxies, API gateways etc.) have created an environment where relevant data (for API enablement) can be routed through secure and controlled channels.?
Architecture Patterns
Figure 1 above shows the journey of enterprise IT architectures from the primitive point to point integration stages to highly inter-operable styles.
As we can see, in the modern paradigm, our goal is not just to access data through systems and tools but also to expose it as APIs to the outside world. Exposure of this data as managed services across organizational boundaries needs loosely coupled, scalable deployment architectures and processes. In order to meet these requirements, IT architectures transformed itself from component-based monolithic assemblies to independently deployable microservices.
In the traditional pattern, the components attain value only within the context of a larger product and are designed to serve a specific purpose (e.g. ERP, CRM systems, etc.). Whereas in a microservices development style, each service is designed to deliver business value independently at a lower level of abstraction (e.g. pricing APIs, specific customer information APIs, etc.). These microservices can further be combined and composed to create Process APIs and applications at higher levels. This paradigm ensures risk isolation, accountability, and predictability while conducting new experiments on value creation.
Development and Operations Processes
In order to develop and maintain such models, development teams should also operate in an agile and frictionless manner. In line with this, SDLC methodologies too evolved to keep pace with the technical changes. For instance, modern development processes such as Scrum, Kanban, etc., with continuous integration and continuous deployment (CI/CD) tools are designed to deliver business value at the micro-level in the shortest possible timeframe without long release and testing cycles.
Fears Around Data Security are Allayed by Technology & Regulations
Technical possibility and utility alone are not the sole determinants for decision-makers to adopt a successful API strategy. It should also be robust and secure. Without adequate mechanisms to prevent unnecessary exposure of data to the outside world, an API strategy would fail to gain seriousness among CXOs.
Today, organizations are armed with techniques at multiple levels to secure flow of data via APIs. These include:
Conclusion
In short, API enablement is no longer a good to have feature but is all set to be the core strategy for the digital transformation of businesses. Maturity on technical, process and regulatory aspects make it even more compelling to adopt the same for revenue generation.