What is an API? Its types and protocols used
Introduction
Imagine you’ve gone with your family to a restaurant for dinner. All of you want to have your favorite delicacies in front of you. The kitchen’s there, the utensils are there. But does the place’s management allow anyone to straightaway go into the kitchen and use it? No right! Instead, a waiter comes up to your table, takes the order request, goes to the chef and gets back to your table with the order after some time.
The restaurant management wouldn’t allow people who are not authorized to access certain places (in this case, the kitchen). Here, the waiter acts as an interface between you and the restaurant. It is the exact task of an API in software development.
An API, or Application Programming Interface, allows unrelated software products to integrate and interoperate with other software services and data. It acts as an intermediary layer that processes data transfers between systems, letting companies open their application data and functionality to external third-party developers, business partners, and internal departments within themselves.
The user interacts with the system through the user interfaces. Similarly, an API exists for the software to interact with each other, such as executing instructions, fetching data from servers, etc.
How an API works
A simple way to understand how APIs work is to look at an example like third-party payment processing. Let’s say a user is ordering a product on an e-commerce website. On the mode of payment selection page, a prompt appears saying “Pay with Paytm” or some other third-party system like PayPal, etc. This function is now API-dependent.
When the buyer clicks the payment button, an API call is made to retrieve the user’s information. This request is processed on the payment services’ end via the API’s URI (uniform resource identifier) to validate this request.
The third-party system validates and performs all the checks on the user’s account level without displaying any information on the screen. Afterwards, the server sends the response back to the initial requesting application, here the e-commerce platform.
While the data transfer depends on the type of service, protocols, and formats used for the requests and responses that happen through the API, there is no visibility on the user interface, and all a user sees is a seamless connection between different services that appear to be working as one.
API or Web Service — confused between the two?
According to W3C, Web service is a software system designed to support interoperable machine-to-machine interaction over the internet. Wait a second, this does sound a lot like API, right?
While the two terms are used interchangeably, there is a slight difference between them. Web services are a type of API that are accessible through the network. All web services are APIs, but not all APIs are web services.
- The difference between an API and a web service is that API allows two-way communication and web services (through web applications) are just a way for users to interact through a web browser. A web service may have an API to complete the requests.
- Webservices are used for REST, SOAP, and XML RPC protocol-based communication, while APIs can be used for any mode of communication.
- Another considerable difference between the two is the format they support. Webservices only support HTTP protocol and XML message exchange format for requests and responses, whereas APIs support both XML and JSON message exchange formats along with both HTTP/HTTPS protocols for communication.
Types of APIs
By “type”, we mean the scope of use of the API. There are four different types of APIs used in web services:
- Public APIs
Also called open or external API, public APIs are those that are made available to be used by any other developer/business. Such APIs usually have low to moderate authorization and authentication. While many of the open APIs are free to use, certain publicly available APIs do charge money on the basis of their usage, and might apply rate limits as well. - Partner APIs
Partner APIs are made to handle business-to-business activities and are made selectively available to developers outside the parent organization. These APIs impose stronger rules and guidelines around authorization, authentication and security. A business organization might share its customer data with external parties through such partner APIs having dedicated rules defined. No other API is used. - Private APIs
Private APIs are used within the organization, like between the HR department and the payroll team. These are made to connect the internal systems and data in the business. Usually, since there is no connection with the outer world, such APIs might opt for weak or no security at all. This, however is changing and companies are imposing strong security to match the regulatory compliance demands. - Composite APIs
Composite APIs combine multiple API requests into one call to form a solution for a complex problem. This saves data and makes the application efficient by reducing the number of API calls the system makes.
GraphQL can be said to an example of composite APIs, as it consolidates all queries to a single endpoint and returns precisely what the client requests to avoid over and under fetching. Though the developer has to tightly bound the requesting payload, it reduces the number of API calls and thus, makes the system faster.
API Protocols
Every API has a defined set of rules and techniques that should be followed by the developers to incorporate them in their software. These rules govern how the API implementation should be done, and how APIs should be used. These rules are termed as API protocols. API Protocols define the accepted commands, data types and formats to be used, along with a lot of other things.
Popular API Formats being used are –
SOAP
SOAP stands for Simple Object Access Protocol. It’s being still used even though it was started in 1998. In SOAP, we use XML as the only message exchange format for both requests and responses. SOAP is highly structured in nature and requires a standard format for all XML requests and responses.
REST
It stands for Representational State Transfer. REST is more of an ‘architectural approach’ for designing APIs. It’s stateless in nature, and therefore does not enforce messages to be in a specific format like SOAP does.
A REST API endpoint is a URL that utilizes HTTP verbs to execute CRUD (Create Read Update Delete) operations over the resources. These HTTP verbs are GET, POST, PATCH, PUT and DELETE. It focuses on providing resources from the server to the clients.
RPC
To understand RPC, it is like you are working on a program, and upon running a certain function, it triggers a function call to be executed that is running on another computer connected to yours through network. The other computer receives your request, processes it, and returns the response to your system to be used for further processing.
For a common person’s understanding, lets say you are working in your office and want to have cookies made by your mother specifically. What you do is email her asking her to send a box of your favorite cookies. This is an example of RPC. Of course not anyone can do a RPC. There are rules for authorization and authentication. In this scenario, someone from the family only will call for the delicious cookies :)
Remote procedure call (RPC) is an Inter-process communication technology that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction. RPC is more powerful than REST, but at the same time, harder to use.
XML-RPC
The XML-RPC protocol relies on a specific XML format to receive data. Being older than even SOAP, it’s lightweight, simpler and requires much less bandwidth.
JSON-RPC
As the name suggests, it relies on JSON format to receive data.
gRPC
Developed initially by Google and then open sourced, gRPC is a high-performance open source RPC framework.
Unlike above protocols, gRPC lets developers define their own custom functions to enable inter-service communication as required. gRPC uses HTTP as its transport layer and provides additional facilities such as authentication features, timeouts, flow control, etc. Data is sent in protocol buffers (called protobuffs), a language and platform independent mechanism which defines how data can be structured in a simpler intuitive way.
Protobuffs begin with defining the service first, followed by defining the data structures the service will use. This is compiled by the compiler protoc, which now creates an entire class furnished with your defined data types along with basic set methods in the development language you’re working on. Now, this class can be used to implement the detailed workings of the API.
GraphQL
Developed by Facebook (now Meta), GraphQL is a query language for your API, where you define the format in which you want the data. It is a strongly typed query language that queries data from the server, in the exact format specified by the developer in the request.
That’s it for this blog. In the upcoming blogs, we’ll be discussing about the differences between REST and SOAP to more extent. And then, understanding GraphQL basics, how to use GraphQL and we’ll be working on setting up a project utilizing GraphQL, Postgres and JavaScript.
Thanks for reading. If you liked it, your feedback is truly appreciated.
For more content, do check my other blogs!! ✌