Assuming you know what APIs are and the general idea of their uses, let’s scratch the surface and get some more out of APIs. First of all, there are various kinds of APIs and there is no one size fits all way of using them. These decisions solely depend on the need and purpose of the business, API types, protocols, and architecture.
There are various types of APIs out there, primarily you will come across four types more often than any other ones. These are – Public, Partner, Private and Composite APIs, used in web applications. Let’s look at each of them.
Public APIs
Public APIs, as the name itself suggest, are made open to public use. The term ‘public’ is quite ambiguous here. This is to say, the API is built and released outside for other developers or businesses to use it. This can be an enterprise as well that share its data and application with other business for a variety of purposes.
There are tons of public APIs out there, for instance, you can use Windows API and build an application for Windows. They made their API public. Generally, Public APIs require some degree of authorization and authentication and you are good to tap in.
Partner APIs
These are the kind of APIs, that can be used by selected only outside developers or businesses. This is, generally, to leverage the ease of activities between businesses. The partner that needs the data from this API will only be authorized to get the data using this API only but no others.
It is due to this strict nature, partnering APIs are typically quite strict with authorization and authentication. This API imposes heavy security.
Internal APIs
Internal APIs are primarily used within the business to carry on business activities and are not exposed to outside use at all. It is used to carry on the internal business activities and connect the level of the business according to their demand.
Internal APIs typically impose low to no, authentication, or authorization since it is strictly used within the business only. The security levels are confined within their policies and penalties. Although, due to the growing cyber security threats, businesses are modifying this and considering the imposing level of security.
Composite APIs
This one is like a hybrid API. You are able to combine two or multiple APIs to suit the business cases. There is an upside to using a composite API like optimum performance and speed over others.
Now let’s take a look at the architecture and Protocols for APIs. Every API need some clean architectures and protocols for them to work effectively. Since API is used to transfer and exchange data and commands, failing to design a clean architecture for API can result in drastic API of no use!
There are three types of API architecture/protocols out there that are widely used to varying degrees. These are – REST, SOAP, and RPC. Each of them comes in with their performance and trade-offs based on their respective nature.
REST
Earlier we mentioned REST API. REST stands for Representational State Transfer and it is built on such architecture. This is considered one of the most novice and widely approached architectures when comes down to building an API. Even though the ‘novice’ term is mentioned here, this does not make this API less effective, rather most flexible. REST API communicates via the client-server method used in TCP protocol. REST API is not responsible for storing data, or the status of the requests. Best for caching in case of slow APIs.
RPC
This stands for Remote Protocol Call. RPC is used, when there is a need for a simplistic means of exchanging multiple parameters and results. This API is based on sending or receiving executable actions, whereas REST API is used to exchange lightweight data like documents. The most used format with RPC is the JSON and XML. They are dubbed either JSON_RPC or XML_RPC.
SOAP
SOAP stands for Simple Object Access Protocol (SOAP) is a standard defined by W3C (World Wide Web Consortium). SOAP is widely used for creating web APIs commonly with XML. SOAP can exchange data over a wide range of protocols found on the Internet. Such as HTTP, SMTP, and TCP. In terms of flexibility to the core, SOAP offers extensive addition to functionalities and features. SOAP is also well and definite in terms of structure and control. SOAP also comes in with built-in error handling, unlike REST.
Which one to use and which one is better than others, depends on the need of the business. Each of these APIs has its own trade-offs.