Types of APIs and Everything You Want to Know About APIs

We generally talk about APIs in terms of consumers and providers. If you are a developer building an application, and you are going to use an API that’s out on the internet, you are considered the consumer of the API – the consuming developer. You are the API consumer. However, if you are an organization who is putting an API onto the internet so that developers can consume it, you are the API provider. For example, Google Maps API is on the internet. Why would anybody do this? Well, it turns out if you are an application developer, you can outsource certain requirements of your application to an API.

 

For instance, instead of writing the code you would need to paint a map in your application, you can outsource that with one line of code to the Google Maps API. This is a good example of how you might outsource some kind of functionality to your application. In order for this to happen, there must exist a technical contract between the two parties. An exact understanding must be there between the application that is consuming the API and the API provider. This is imperative, because if that understanding isn’t exact, then the actual API transaction will break down. It is like a legal contract. For example, when a footballer signs a contract with a team, both parties are bound to certain performance by that contract. The player must deliver certain performance on the field, while the team must pay the player a certain amount of money for that performance. APIs are no different – there is a contract that exists between the consumer of the API and the provider of the API in the way that performance of both is required. The contract usually represents some agreed-upon standards on exactly how the information or functionality – like drawing a map – is going to be exchanged.

Simply put, if APIs weren’t there, you won’t be able to order your favorite golf club on Amazon, buy Bitcoins or personalize your Google homepage with mini-applications. An API allows one application to interact with another through commands that are designed by programmers. APIs aren’t something new – whenever you use a computer, APIs are what allow you to move data between various applications. For instance, when you copy an image from an email into a Word document, APIs enable this movement of data. Low-level APIs make it possible for different applications like Dropbox to run on an operating system like Windows.

 

On the web, we can think of APIs like a telephone – when a certain application wants to acquire information from another, it calls the APIs of the second application. For example, if you wanted to build an application that showed people the restaurants that are liked by your friends, you could use the Facebook API – to acquire data about what your friends like – and the Yelp API – to get data about restaurants. When your application is opened, the code of the application would call the Facebook and Yelp’s APIs to get the data it needed.

 

In the world of Web API, big services such as Google Maps and Facebook allow other small applications to acquire their data. For example, LinkedIn and other applications allow users to sign in their Facebook account. This happens through the API of Facebook. Many websites use Google Maps API to show locations on the Google Map.

 

APIs do all these things by exposing a piece of the internal data and functionality of the software to other applications in a controlled manner. This enables one application to share its data and perform actions on behalf of another without requiring developers to share their entire code. Sharing data at such a scale would be inefficient. Moreover, it would pose major security threats. APIs enable this kind of integration without sharing the code that is making the software run. They are even useful for open-source software (where the code is publicly available). Most developers generally don’t have the time to look through hundreds or thousands of line of codes to perform one function. Instead, they use API to perform that function.

 

If APIs weren’t there, applications would be disconnected and confusing. APIs enable different applications to communicate with one another, allowing more consistent and innovative applications to be built. For example, if Google Maps didn’t have an API, every website and mobile application would have to determine how to implement a mapping system of their own. This would be a very difficult task.

 

APIs can also be internally useful for a firm in addition to allowing companies to share resources with other firms. For example, a developer at Goggle could create a single API to support all of the Google applications used by users. Instead of duplicating code for each of the other application, they would be able to share data through a single API. API simplifies the complexity of development by limiting access to a specific functionality. Due to this, developers can build new software in weeks or months instead of years.

Because APIs allow developers to engineer new applications that plug into major services – social networks such as Facebook or Instagram, or utilities such as Dropbox, they are essential in the modern- day and age. The developer of a mobile game, Clash of Clans, for instance, could use Dropbox to allow players to store their saved data in Dropbox’s cloud instead of creating a new cloud storage system. Or a software developer who is creating a mapping application could use the Uber API to allow users to hail a ride.

 

APIs can thus be timesavers for both users and software developers. For instance, if the Facebook API didn’t exist, then users would have to create an account on every application instead of logging in through Facebook. APIs allow modern experiences on the internet to work extremely well. Developers can use different APIs and mash them to offer new experiences to the users. From Facebook, to Twitter, to Google, software developers can pick thousands of APIs to use in their applications.

 

For example, when a user searches for nearby restaurants on Yelp via their iPhone, the app uses Apple Map to plot their location instead of creating its own map from scratch. API is what makes this all possible. The Yelp app passes the locations that it wants to be plotted on the Apple Maps API and this returns a map with the restaurants pinned on it. Yelp then displays this to the user. Mobile devices such as Android phones and iOS have many different APIs built-in. For example, ‘Healthkit’ is an API created by Apple that allows software developer to access the health data of a user from a central place.

 

Another simple application of APIs is the sharing icons you see on videos, blog posts, and articles across the web. When you click on their shareable links, an API is called that enables users to post or Tweet about an article without ever leaving the website they are on. The commenting system featured below many videos and articles is another example of API. It lets users post comments without having the owner of the site do anything extra. APIs have enabled the pace of innovation to rapidly increase, where each new developer can create functionality without doing a lot of work.

Companies often use APIs for making money. API business models allow firms to further their business objectives through their APIs. In a free API, an organization or a company gives access to its API without any cost. The reason is that having developers use their API allows them to increase the reach of their firm or allows the firm to reach more users. Another model is called the ‘developer pays’. In this type of API business model, the data provided through the API is valuable and as such, developer must pay to access it. PayPal is an example of this type of API where the user must pay for accessing its payments. PayPal charges a transaction fee for every single payment made via its API. The developer that gets paid is another API business model, where the company pays a certain amount to the developer for using its API.  This usually comes as part of a revenue-share or affiliate program where a developer using the API can get paid for every lead they send to the website through the API. Amazon.com is the perfect example of this, where the developer is paid a commission for every sale they generate using the API. Indirect API models cover all of the other ways for firms to benefit from APIs.

The infrastructure of most organizations today is highly intertwined, where you don’t know where one thing starts, and another ends. This creates a very difficult problem when it comes to maintaining an infrastructure.

 

Monolithic applications are very large and complex. They are also highly intertwined in a way that if you make a change at one place then you won’t exactly know where else that change is going to impact other parts of your monolithic application. You may not know until you make the change. When you make the change, you could have breakage and you are going to have to go back to fix it. This can make the maintenance of such large monolithic applications very cumbersome, time-consuming and costly.

 

One of the major problems is that with a monolithic architecture you often have multiple developer teams touching the same part over and over again – maybe contributing conflicting source code in a way that produces ongoing problems with compatibility and functionality of your applications. These organizations problems will make everything slower which isn’t a good thing in today’s environment. It may take you months or maybe years to put in place new changes because you still don’t know how one change is going to impact your monolithic infrastructure. This is a sort of slow speed that most organizations today cannot survive and it also makes them far less competitive against organizations who might have figured out how to speed things up primarily by transforming their company into an API-led organization. Development schedules get very long and it could take even years for the completion of projects whereas when you have API-led connectivity in the seams between your applications it could take hours or days for a developer to complete a project.

 

What if you took all of those parts that were overlapping in a monolithic application and spilt them apart, by decomposing them into their own parts. Then what if you took those same parts and turn them into services. Instead of direct integration between parts, you put an API layer around them so that you have consumers and providers of APIs within your organization. Now what you are doing is creating these seams, where there are very clear lines of responsibility within your organization, and you are turning your entire infrastructure into what we call a services-oriented infrastructure.

 

The basic principle is that you take all of the parts of your infrastructure, decompose them into discrete parts that each turn into a service and that service is now delivered to the other parts of the API. This is a very sound approach to business transformation.  Now, suddenly you are going to start experiencing the competitive advantages of transforming your business. For example, because you are delivering certain functionality as a service to another part of that old monolithic architecture, you can more easily make changes to that service, while the contract of the API stays the same.

 

For example, if it is too expensive to run that service or it isn’t going fast enough, you can replace the infrastructure behind it in a way that either drives the cost down or the performance up. Also, you may discover that your infrastructure, includes a bunch of parts that are either redundant or that you as an organization, should not be providing. We always hear the story about only focusing on building stuff that matters to your competitive advantage. Well, mapping technology is probably not to your advantage, if you are building it from scratch. You can outsource that to some other service provider like Google through an API.

 

You may discover that when we decompose that big monolithic application, there are a whole bunch of opportunities to take parts out and replace them with off-the-shelf parts that are out on the net and available via API. These off-the-shelf parts won’t only be more advanced in the way they operate but are also less expensive for you to acquire and include into your application infrastructure.

 

Many companies have embraced this form of culture. Still there are none that did it the way Jeff Bezos – the chairman and CEO of Amazon – did it back in 2002 when he announced that from now on all teams will take whatever functionality or data they are providing and turn it into a service that’s available to the rest of the company. He also said that the only way anybody else in the company can access that functionality or that data is through that services-oriented interface or through that API. If you did it any other way, you’ll get into a lot of trouble and in fact, you would get fired. Now there would be no form of in-a-process communication allowed that’s it, period. You had to go through those API’s through the network and it didn’t matter to Jeff which technology the employees used to create a service or provide a service as long as it was of service. Later maybe they standardized on some very standard approaches to how exactly to offer APIs but in the beginning the key was just to get services-oriented interface around all of that functionality. Finally all teams without exception had designed these interfaces in a way that they could be externalized. What we mean by that is that not only could they be offered internally to other Amazon departments but they could be offered externally to the world as a public API. We know where that went because now Amazon is one of the biggest API providers on the planet and a good chunk of their business is derived through the consumption of their APIs. How can you do the same thing?

 

Well, what we are talking about is taking a monolithic interface that is highly intertwined and breaking it up into discrete parts each of which has its own specific interface. One way to approach this is just try to think in seams – where are the most natural places where I can take my existing infrastructure and decompose it so that I can arrive at something we call micro-services architecture. The chief benefits of micro-services architecture particularly when we are talking about decomposing and then reassembling your information architecture is that you have smaller discrete sets of services that are focused on one or two functions and that the lines of division between them are very clear using APIs. Moreover, development teams are only focused on their area of responsibility. No two development teams are working on the same thing at the same time and the contracts between all those moving parts are strongly maintained throughout the process. If at any time one development team has to change a contract of the APIs around the services that they have built, they have to notify all the other teams that a change is coming. This makes it a lot easier to introduce changes into your application architecture at a quick speed as compared to six months or a year. That’s what business transformation is and that is how you can take your business to the next level and stay competitive.

There are opportunities to secure the API transaction at different parts. There is security that you can put on API consumer or the client. You can also secure the API network to ensure that the data passing through the network is secured. There is also security that you can put on the API server or the end user.

 

There are certain areas of risk along the API transaction. On the client end, you have the app source code that is running. That app source might be discoverable by hackers. You have to be very careful about all of the different ways you can secure your source code and also keep any confidential information that might be in the source code itself from falling into the hands of hackers. Shared passwords are another problem – this is where you are using the same id/password to log into different services. Why do we do that? We subscribe to thousands of services and it is impossible for us to remember all of those passwords so we often use the same password across multiple services. Why is this a problem in an API network? It is because if we use a password to log into some service and the same password to log into another service and the hacker discovers that password, they will have access to multiple services. This is why you shouldn’t use the same password in an API economy.

 

On the backend of the API network, there are all kinds of security risks. SQL injection is a common problem and many hackers use it to penetrate databases. Rate limiting is another issue. A lot of API providers forget to put rate limits on their API. Rate limit is the number of times that an API consumer can come and hit your end point over a given period of time.  Improperly secured endpoints is another problem in API networks. Endpoint is where the call to an API is actually made.  It is very important to secure the endpoints in the network. Phishing and social networking attacks are a big way that hackers use to crack into an API and take advantage of any vulnerabilities they find. Many of the different attacks that we have seen in the past started with phishing attacks.

A key concept here is this idea of a service level agreement (SLA). SLA tier defines the level of service that is being sold which basically translates to how often a user can hit an API. It allows the API owner to define the menu of offerings that they are making available to API consumers. For example, maybe you are starting off with a free tier so that an API consumer who is just testing out what they can possibly do with that API can use it. They can make one call and see what comes back to them.

 

Layered SLA tiers can also be used by an API owner, which allows them to impose multiple throughput limits. For example, you might be able to configure your API in such a way that the consumer can only hit it hundred times per second or 5,000 times per second.

 

An API manager tool is extremely useful. This actually allows applications to talk to each other. Remember that a user isn’t the one requesting access to an API it’s an application that requests access to an API and an API manager tool is what allows you to manage the interface for the application requesting access to an API. For example, you might have an application requesting a specific SLA tier and you can use an API manager tool to define how many requests are going through per minute and how many requests are going per hour. SLA don’t do anything themselves and you need policies to enforce anything. SLAs are just a packaging tool that allows you to group your consumers together into understandable bites.

Now that you have gotten an understanding of APIs and how they work, let us take a look at different types of APIs that are currently available. APIs perform similar functions but they can be different from one another in some ways. In terms of release policies, APIs can either be partner, private, or public.

These APIs are openly promoted and shared with the partners who have signed an agreement with their publisher. Partner APIs are mostly used for software integration between parties. A company that gives partners access to functionality or data of an API benefits from extra streams of revenue. Moreover, it can monitor how their digital assets are being used by developers, ensuring that the partners are using their APIs to provide good user experience.

Private APIs are designed to improve services and solutions within a firm. In-house developers may use private APIs for integrating an organization’s applications or system, build new system or apps that leverage existing systems. Even if the systems or apps are made available to the public, the interface itself will only be available to those who are working with the publisher of the API. The company is in complete control of a private API.

Public APIs or external APIs are available for third-party developers. When properly executed, a public API program allows a company to increase its brand awareness and receive an additional source of income. Public APIs are further divided into open APIs and commercial APIs. Open APIs are public and their features can be used without any restrictive term and condition. For instance, a developer can utilize an Open API to build an application without approval from the supplier or paying any licensing fee. API description and related documentation is openly available and the API can be freely used for creating and testing applications. Developers who use commercial APIs must pay subscription charges.

APIs can also be classified into different types, based on the systems they are designed for:

These APIs allow a database management system and an application to communicate with each other. Developers write queries to access data and change tables, etc. within databases. For example, the Drupal 7 Database API allows users to create unified queries for various databases, both open source and proprietary. ORDS database is another example, and this API database is embedded into Oracle REST Data Services.

These APIs define how services and resources of an operating system are used by applications. Every operating system has its own set of API. For example, the API of windows is referred to as Windows API and the API of Linux is called Linux API. In the developer documentation of Apple, API reference for iOS and macOS is found. APIs for creating applications for macOS operating system can be found in the Cocoa set of developer tools. Cocoa Touch – Cocoa’s modified version is used by developers who are developing apps for iOS mobile OS.

These APIs define standards of communication for apps that are running on various machines. In other words, a software accesses resources that are located outside of the device requesting them. Since two applications that are remotely located are connected over a network, most remote APIs are created based on web standards. Java Remote Method Invocation API and Java Database Connectivity API are example of remote APIs.

Web APIs are the most common. These provide machine-readable functionality and data between web-based systems representing client-server architecture. Web APIs mostly deliver requests from web applications using HTTP (Hypertext Transfer Protocol). Web APIs can be used by developers to enhance the functionality of their sites or apps. For instance, Google Maps API allows the developer to add a map on a website or app.

APIs specifications standardize exchange of data between different web services. Standardization means the ability of different systems, written in various languages and/or running on various operating systems to communicate with one another. Different API specifications/protocols are in place. Some of them include:

Web APIs might have to follow resource exchanged principles that are based on a RPC. This protocol specifies the communication between client-server based applications. One program requests functionality or data from another program that is located in another system on a network and the required response is sent by the server. RPC is also called a function call or subroutine. A remote procedure call can be implemented through SOAP.

Soap is a protocol for exchanging information in a disturbed, decentralized environment. This specification generally contains the syntax requirements for requesting and responsive messages that are sent by web apps. APIs that comply with SOAP principles enable XML message between different systems through SMTP (Simple Mail Transfer Protocol) or HTTP for transferring mail.

 

XML is a flexible and simple text format that is widely used for data exchange or storage. It defines rules for encoding documents in a format that can be read by both machines and humans. XML language is contains systems that can be incorporated in the text for labeling and delineating the parts of a text document. XML documents comprise of self-descriptive tags, which make them easily readable.

 

SOAP is often used with enterprise software for ensuring top security of the transmitted data. Providers of CRM solutions, identity management solutions, payment gateways and telecommunication and financial services prefer SOAP APIs. PayPal’s public API is a common example of SOAP APIs.

A computer scientist named Roy Fielding introduced the term ‘REST’ in a dissertation back in 2000. SOAP is a protocol, while REST is a software architecture style that contains six constraints to build applications that are capable of working over HTTP. World Wide Web is a common application and realization of REST.

 

Many developers find SOAP difficult to use as it requires writing several lines of code to complete one tasks and following the XML style for every message. REST is an easier alternative to SOAP that follows another logic, making data available as resources. A unique URL is represented by each resource and one can request this resource by providing the resource’s URL. Web APIs that are compliant with the architectural constraints of REST are known as RESTful APIs. These APIs utilize HTTP request to work with different resources including GET, HEAD, PUT, POST, CONNECT, TRACE, DELETE, OPTIONS, and PATCH.

 

Messaging is supported by RESTful systems in various formats, such as YAML, HTML, JSON, and XML, while SOAP only lets developers use XML. The ability of supporting multiple formats to store and exchange data is the main reason REST is the preferred choice to build public APIs. Travel companies and social media giants use external APIs for improving their brand visibility. For instance, Twitter has several RESTful APIs, while Expedia has both RESTful and SOAP APIs for its partners.

 

JavaScript Object Notation (JSON) is an easy-to-parse text format for the exchange of data. Each JSON file has collections name, value pairs and ordered lists of values.

API would remain unusable, if developers did not know or understand how to use and work with it. Structured and well-written API documentation that explains how to use and integrate an API is an easy-to-understand way to make a developer happy and more likely to recommend the API to their peers. The API documentation is a manual, with all the information about the API including arguments, return types, classes, and functions. Numerous elements make good API documentation, such as:

* A quick-start guide

* Authentication information

* SDK examples showing how to access the resources, etc.

* Explanations for API call

* Examples of request and return with an error message, response description, etc.

* Examples of code for major programming languages such as Java, PHP, Python or JavaScript.

* Tutorials

 

Documentation may be interactive and static. The former allows developers to try out APIs and check return results and it usually consists of two columns – machine and human. The machine column has a console for making calls and has information that servers and clients will be interested in while the human one contains API descriptions.

 

Final Thoughts

APIs are extremely useful in today’s competitive environment. They are a critical component to integrating data flows with partner systems and customers. Companies continue to recognize the potential of APIs and many are using them to improve speed, efficiency, accuracy, and consistency in their operations. Without APIs, the world of IT wouldn’t be the same. In the next few years, we expect to see more development in APIs.

 

We hope you now understand what an API is, how they are used, how they work and how important they are in today’s market. We have also provided information on different types of APIs so that you understand how various APIs work. If you have any questions about APIs or in case something is unclear, feel free to reach out to us.