API

What is an API?

• API stands for - Application Programming Interface
• A set of protocols that allow different applications to communicate and exchange data.

Why do we use it?

• API helps to integrate the existing functionality with a new application.
• Avoid code to be written from scratch
• Helps in sharing data

How it works?

An API explains the WHAT part, and not the HOW part to the users of the API. What do I mean by this?

There is a famous analogy of a Customer visiting a restaurant and getting the food ordered from a Waiter. The waiter takes that request to a Chef. And when the food is ready, the waiter collects the ordered food from the Chef and delivered it to the Customer.

Here waiter acts as an API, and the customer and Chef act as Client and Server respectively. The Customer can ask for customized food by asking the waiter but is not necessarily aware of the making of that dish. Similarly, when a client requests some resources from the server, the client can ask what it wants but is not aware of how the API works.

Another example is when you hit any keyword for a search on google.com. What exactly happens? You and your pc act as a Client, and the keyword that you hit, act as a GET request to the Google server. And the results that are being displayed on the page act as a response. Here, you are only aware of the WHAT part, which means you're searching for something and get the result accordingly; but you don't need to know exactly how the search engine works.

Types of APIs

In terms of Architecture style

API exchanges data based on cearly defined protocols and architectures - the rules, structures, and constraints that govern an API's operation.

There are 6 main categories of API protocols or architectures:

REST or RESTful API

• stands for REpresentational State Transfer (REST)
  • is a way for two machines to transfer the state of a resource via representations
  • There are multiple representations such as JSON, HTML, text, etc.
• this is the most popular API

• 6 constraints followed by RESTful APIs

  1. client/server
     • The client is someone who is requesting resources and is not concerned with data storage
     • server is someone who holds the resources and is not concerned with the user interface or user state
  2. stateless
     • The server will not store anything about the latest HTTP request the client made
     • every request is treated as new
     • No session, no history
  3. Uniform Interface
     • A resource in the system should have only one logical URI, like naming conventions, link formats, or data format (XML or/and JSON)
     • Naming conventions Example:
       • good example: /api/users
       • bad example: /api?type=users
  4. caching
     • caching of data and responses is of utmost importance wherever they are applicable/possible.
     • The webpage you are reading here is also a cached version of the HTML page.
     • Caching brings performance improvement to the client side
     • Caching can be implemented on the server or client side.
  5. Layered
     • architecture where you deploy the APIs on server A, and store data on server B, and authenticate requests in Server C.
     • for example. A client cannot ordinarily tell whether it is connected directly to the end server or an intermediary along the way
  6. Code on Demand (optional)
     • Most of the time, you will be sending the static representations of resources in the form of XML or JSON
     • But when you need to, you are free to return executable code to support a part of your application, e.g., clients may call your API to get a UI widget rendering code

SOAP API

• simple object access protocol

RPC API

• remote procedural call

GraphQL

• GraphQL

WebSocket

• WebSocket

Webhook

• Webhook

In terms of Consumer usage

There are no differences from an implementation perspective for these APIs: - Private or Internal - Public or External - Partner