API Breakdown: What is an Application Programming Interface?

API Breakdown: People working together planning out their API intentions

 

API (Application Programming Interface) Breakdown: An API is an application programming interface, briefly described as a software middleman that allows two applications to communicate with one another. Every time you use an app such as Facebook, Weather Apps and Instant Messengers, you’ll most likely be using an API.

The function of an API is to access the data from one particular piece of software and to make sure it’s compatible with any interacting software. In most cases, the end users of an API never directly interact with the API but instead enjoy the benefits once a request is complete.

Due to the sheer usefulness of APIs, you’re likely to encounter several different APIs throughout your everyday life, whether you’re aware of it or not. So APIs are the primary software infrastructure for ensuring that most software can work together in unison.

 

Examples of such APIs include but are not limited to:

  • Twitter Bots
  • Log-In Using XYZ
  • Weather Snippers
  • Pay with PayPal
  • Google Maps
  • Travel Booking
  • E-Commerce

 

 

Data Flow & Types

To understand how APIs work, you must first understand an API’s data flow and key terminology used. A simplified example could be when you sign into Facebook from a device such as your phone, telling the Facebook application that you wish to access your account. Following this, the application would then make a call to an API asking to retrieve your Facebook account and details. After this, Facebook would grab this information from their servers and send the data to the application.

Another popular analogy is to think of the API as a waiter or waitress in a restaurant. After deciding what you want to order, you would then relay this to the staff, who take this request to the kitchen and deliver your request to the chef. The result is that the waiter will bring your order to you accordingly.

 

API Breakdown: WEB APIs

There are four types of web APIs:

APIs are widely accepted and used in most applications because of their many benefits. There are four main types of API commonly used in web-based applications: public, partner, private and composite. In this context, the API “type” indicates the intended scope of use.

 

Public APIs

A public API is open and readily available for use by any developer or business. Businesses that share their applications and data with others will often develop and offer these APIs.

Typically, public APIs involve moderate authentication and authorisation and rarely require any costs unless the API provider decides on a per-call basis.

Partner APIs

Partner APIs are usually only available to specifically selected and authorised users, developers or API consumers to facilitate business-to-business activities. Partners have clear rights and licenses to access such APIs. For this reason, partner APIs generally incorporate stronger authentication, authorisation and security mechanisms.

Internal APIs

An internal (or private) API is intended only for use within the enterprise to connect systems and data within the business. For example, an internal API may connect an organisation’s payroll and HR systems.

Internal APIs traditionally present weak security and authentication because the APIs are for internal use.

Composite APIs

Composite APIs are generally a combination of two or more APIs to craft a sequence of related or interdependent operations. These APIs can be beneficial in addressing complex API behaviours and sometimes improve speed and performance over individual APIs.

 

 

API Breakdown: Protocols and Architectures

APIs exchange various commands and data; to accomplish this, they need clear protocols and architectures, essentially the rules and structures that decide how an API operates. There are three main API protocols and architectures categories: REST, RPC and SOAP. These “formats” each offer unique characteristics and pros/cons.

 

REST (RESTful) API — stands for representational state transfer and delivers data using the lightweight JSON format. Most public APIs use this because of its fast performance, dependability and ability to scale by reusing modular components without affecting the system as a whole.

 

SOAP — Simple Object Access Protocol is a little more complex than REST because it requires more upfront about how it sends its messages. This API has been around since the late 1990s and uses XML to transfer data. It requires strict rules and advanced security that requires more bandwidth.

This protocol does not have the ability to cache, has strict communication and needs every piece of information about an interaction before any calls are even thought of to be processed.

 

XML-RPC — known as an extensible markup language — Remote Procedure Calls. This protocol uses a specific XML format to transfer data and is older and more straightforward than SOAP. A client performs an RPC by sending an HTTP request to a server that implements XML-RPC and receives the HTTP response.

 

JSON-RPC — is very similar to XML-RPC in that they work the same way, except this protocol, uses JSON instead of the XML format. The client is typically software that calls on a single method of a remote system.

 

 

API Breakdown: HTTP Methods Used by APIs

 

The Hypertext Transfer Protocol (HTTP) enables communications between clients and servers. HTTP works as a request-response protocol between a client and a server.

Example: A client (browser) sends an HTTP request to the server; then, the server returns a response to the client. The response contains status information about the request and may include the requested content.

1. GET

The GET method retrieves information from the given server using a given URI. Requests using GET should only retrieve data and should have no other effect on the data.

2. HEAD

Same as GET, but it only transfers the status line and header section.

3. POST

A POST request sends data to the server, for example, customer information, file upload, etc. using HTML forms.

4. PUT

PUT replaces all current representations of the target resource with the uploaded content.

5. DELETE

DELETE removes all current representations of the target resource given by a URI.

6. CONNECT

CONNECT establishes a tunnel to the server identified by a given URI.

7. OPTIONS

OPTIONS describes the communication options for the target resource.

8. TRACE

TRACE performs a message loop-back test along the path to the target resource.