📢 Are you a TestProject user looking to migrate to an open source alternative?

Learn more
Different types of APIs and protocols

Different types of APIs and protocols

Hello everyone,

Hope you are all doing well. We are aware that API testing is getting a lot of attention nowadays and we testers are more curious to explore it. But, often we felt lost in the middle of nowhere. It’s because of the lack of the basics. Before handling the API, you should know some basic stuff about that API. What type of API is that? What protocol is used by the API? Sounds interesting? 

Today we will learn about the types of APIs and the types of protocols used by the APIs.

When talking about the types of API, usually people mix them up with the protocol types. Types of API are different from the types of API protocols. Often during the interview as well, I have seen folks who are pretty confused about it. So, I thought of providing better clarity and the difference between them. Let’s get deeper and learn about them.

Types of Web APIs:

Web APIs are the powerhouse and help in integrating internet-based application. They use HTTP protocol for communicating with the browser. Based on the scope, security, and usage they are categorized into four types: Open APIs, Partner APIs, Internal APIs, and Composite APIs.

1. Open APIs:

Open APIs are also called public APIs. As the name suggests, it is available to everyone. They are open for the public to use and integrate with their applications. Developers can easily implement them using minimal authorization. Most APIs don’t require authorization as well. Few APIs require sign-up and generation of the API Keys to access them. 

For example, Google Maps, Facebook, and Twitter are well-known public APIs that any developer could easily access due to the fewer restrictions. 

2. Private APIs:

Private or Internal APIs are developed for in-house purposes. They are mostly developed within the organizations for internal purposes and they are not hosted and made available to the public. Most of these APIs follow stricter security restrictions which makes it tougher for external hackers to break in based on the usage of the APIs. Also, the API documentation for these APIs is maintained internally and not shared publicly. 

All the internal APIs developed by the organizations are good examples of Private APIs.

3. Shared APIs:

Considering the scalability while developing the business, a few APIs are shared across a few other licensed organizations and they are called Shared APIs. These APIs are shared only with the intended users and others might not have access to them because they aren’t shared publicly.

Of course, these APIs require authorization to access them. All the clients who are part of the business access and integrate using those APIs. Few APIs will only provide read access and few APIs will provide read/write access via shared APIs. This depends on the business process model. 

For example, travel booking APIs are shared with travel agencies to increase their visibility and booking. Websites like Expedia, Make My Trip, and Trivago is great examples of shared APIs.

4. Composite APIs:

Composite APIs are the APIs that allow developers to bundle and send requests from different APIs. Usually, one or more related APIs are combined to improve performance. They reduce the load to the server as they are treated as a single call. In the microservices-based architecture single user action might involve multiple API calls. During that scenario, the orchestration of composite APIs is very helpful as this works faster and is easier to implement.

For example, any operation which requires multiple API calls and the output of one request is dependent on each other then the developers handle them as Composite APIs. Similar to ordering via a food app. Using multiple GET calls and retrieving the food and finally placing the request as a POST call. 

Types of Protocols used in APIs:

A protocol includes a set of instructions and formats to follow. APIs developed should also adhere to any protocols from the different lists below:

1. SOAP (Simple Objects Access Protocol): 

SOAP is one of the oldest protocols from the 90s. It is an XML document with components named Envelope, Header, Body, and Fault. The envelope is a mandatory root element of the format. The header is optional, the Body section carries the payload of the request and the Fault is also an optional section that is populated when there are any errors during the transmission. 

SOAP is standardized by the World Wide Web Consortium (W3C). SOAP has strict rules which make security tighter. It is highly adaptable and supports multiple protocols, not just HTTP. It is platform-independent. The size of the message affects the overall performance. Many legacy applications and banking applications still use SOAP. 

Sample Request:

Sample Response:

2. REST (Representational State Transfer):

REST is more of a client-server architecture type and it is stateless. So in REST architectural style implementation of the client and the implementation of the server is done independently. If the format sent by the client is readable by the server it interprets the request and response using the same format.

The Client and Server act as stand-alone components. It communicates directly with the resource called a resource-based approach. Many developers are familiar with the REST architecture and so it is called the developer’s best buddy.

REST uses the HTTP/HTTPS request to communicate between them. RESTful APIs are faster, scalable, reliable, reusable, and preferred in most of the latest developed applications. Also REST uses many payload formats like JSON, XML, HTML, Text etc. Due to many advantages, nowadays we can see more RESTful APIs. But there are some disadvantages as well.

REST doesn’t have any clear, standard reference for implementation, and the data is over fetched most of the time and in turn, this affects the performance. Below are components of a sample request build using REST. 

  • Endpoint: The destination URL of the server
  • Method: It denotes the predefined HTTP methods like GET, POST, PUT, PATCH, and DELETE to process the data. Every method is designed to perform certain actions. Few methods just retrieved the data, few will process and gets the data back from the server and pass it on to the client. 
  • Headers: Headers are the additional information sent to the server to know about the client better.
  • Payload (body): The actual data or the request body sent along to the server for processing

Sample request (JSON format):

Sample response (JSON format):

3. GraphQL:

GraphQL is a querying language. It was developed by Facebook for internal purposes in 2012 and it was open-sourced in 2015. Now it is maintained by the GraphQL foundation. In simple words, you can define your expectations which makes the work easier. Instead of sending all the properties back in your response, you can configure/input what values you are expecting.

When there are umpteen records in the response, this helps you to optimize. It’s as simple as querying the database with the SELECT query and defining the list of fields along with the filter condition. GraphQL supports many programming languages including JS, Java, Python, C++, Perl, Ruby, Scala, etc. JSON is the preferred format for the payload and the responses. There are many more advantages as well. Many developers started using GraphQL for faster and quick implementation. 

Sample request:

Sample response:

4. gRPC (Google Remote Procedural Call):

gRPC was created by Google and made available to the public in 2015. It is a modern, robust open-source RPC framework. It is cross-platform and contract-based. It communicates using HTTP/2 and Transport Layer Security (TLS). Here the data is transferred using protocol buffers which consist of three components. Firstly it starts defining the service or contract using ‘.proto’ files. It is followed by the function code and the language-specific libraries. 

Now, gRPC is used in many famous organizations other than Google. Also, it’s proven that it’s lighter and faster when compared to REST. 

gRPC’s complex use of HTTP/2 makes it impossible to implement a gRPC client in the browser, so this requires a proxy. 

5. RPC (Remote Procedural Call):

RPC is one of the oldest and most stable protocols for APIs. The Remote Procedural Call protocol focuses on actions taken on a server and executes the scripts server-side. It has two major types: JSON-RPC (JavaScript Object Notation- Remote Procedural Call) and XML-RPC(Extensible Markup Language Remote Procedural Call). 

JSON-RPC:

JSON-RPC is a light-weighted, stateless RPC, which is designed using JSON. This is easy to implement and tightly coupled. 

XML-RPC:

XML-RPC invokes the RPC calls and data is transferred as XML files. This is more secure than the JSON-RPC due to the XML encoding. 

6. Apache Thrift:

Apache Thrift was also originally developed by Facebook which is the implementation of the RPC framework. Currently managed by Apache. Here the Thrift files are used for writing the code. It uses a special Interface Description Language (IDL) to define data types and service interfaces stored as .thrift files. The code generation engine develops the code in the preferred programming language. It is flexible and helps to communicate with different systems and different programming languages. It offers many run-time libraries. It is highly scalable. And it’s proven that Apache Thrift is efficient across platforms and languages. 

Final thoughts!!

Ah, that’s a lot of technical stuff, right? Don’t we deserve to know them all as Software Testers? Of course, the selection of API type and protocol depends on various factors like the requirement, business process, and availability of talents and tools. Each of them has its pros and cons. 

We all know a set of tools available for API Testing including many open sources that support API Automation testing. One such tool for API test automation is Testsigma. It is open source and supports automation of web, mobile, and desktop tests as well.

Here is how you can start with your REST API testing with Testsigma: https://testsigma.com/tutorials/getting-started/automate-rest-apis/

But before jumping into API Testing, it’s good to understand the basics of how the APIs work and how they are built, and what the programming language and framework are used for. Learning the technical jargon will help you to build confidence around API Testing. 

After reading this blog, you should now be clear about the different API types and API protocols. We are sure that the next time during your interview you will be able to explain the types and protocols without any hesitation or hiccups. This lays a strong basement for your API journey. Good luck with your APIs!!


Test automation made easy

Start your smart continuous testing journey today with Testsigma.

SHARE THIS BLOG

RELATED POSTS