An Application Programming Interface can be thought of as the way in which programs communicate with each other, accessing data and functionality despite being separate systems. This kind of integration allows for the easy extension of application functionality such as, for example, adding multiple payment methods to a site, integrating social media posts or simply sharing the current weather. APIs make this effortless, leading to more powerful applications.
APIs may be categorized according to these parameters, which will be briefly discussed below:
- Ownership types of APIs
- Communication level of APIs
- Web service APIs
Ownership
There are four ownership types of Web APIs: Open APIs, Partner APIs, Internal APIs and Composite APIs. Ownership APIs are freely available for public use without restriction. These are also referred to as ‘Public APIs’.
- Partner APIs require a specific license or usage rights in order to be accessible. These APIs are not publically available, and are usually used by paid services.
- Internal APIs are, as their name suggests, developed by companies for internal systems and use. These APIs are also known as Private APIs and facilitate integration across services within a company.
- Composite APIs combine a number of different data and service tasks within a single API call. These tasks are executed sequentially. Because these tasks are bundled within a single call, this type of API improves performance.
Communication Level
The second category of APIs is the communication level of APIs. This category comprises high-level and low-level APIs. These ‘levels’ refer to abstraction within the API. High-level APIs are fairly abstracted, meaning they are more generic and, therefore limited in functionality. Low-level APIs are much more detailed and specific due to a low level of abstraction. Low-level APIs allow for finer control over application functions.
Web Services
Third, we have Web service APIs. These APIs use a unique address, called a URL, on the internet to provide access to their services. Web service APIs are categorized according to the type of communication and method of building the API. These categories are:
- SOAP APIs follow a communication standard called Simple Object Access Protocol (SOAP) defined within XML format. SOAP APIs are fairly structured and highly secure which means they cannot be cached. They are also tightly coupled with the server, reducing the ease with which a developer can make changes or updates.
- XML-RPC (Extensible Markup Language – Remote Procedure Calls) These APIs transfer data using a specific XML format. These calls are simpler than SOAP and uses less bandwidth.
- JSON-RPC stands for JavaScript Object Notation – Remote Procedure Calls. These APIs are often used to communicate in microservice architecture. Similar to XML-RPC, JSON-RPC uses JSON encoding instead of XML.
- Finally, we have REST APIs. Representational State Transfer is a protocol for communication that focuses on resource transfer. RPC in comparison, focuses on actions. REST APIs follow a set of principles for how the API is built. These principles ensure that, amongst other characteristics, the API is stateless, cacheable and requires client-server separation. These attributes allow RESTful APIs to be scalable, flexible and easily updated. The set of guidelines for RESTful APIs leads to a more uniform, more straightforward type of API that is more powerful, efficient and with greater browser compatibility.
Working with APIs in Linx
- Design-first APIs: Build and host an API using Linx and Postman
- Code-first: Build and host an API in less than 30 minutes
REST ≠ HTTP
There is a significant difference between a RESTful API and an HTTP API. A RESTful API adheres to ALL the REST constraints set out in its “format” documentation. An HTTP API is any API that uses HTTP as their transfer protocol. This means that even SOAP can be considered an HTTP API, as long as it will use HTTP for transport, but most HTTP APIs will make more and better use of the infrastructure and possibilities of HTTP. Most HTTP APIs can be very close to becoming a truly RESTful API.
Many believe REST and HTTP seem to be hand-in-hand. After all, the web itself runs on HTTP, and it makes sense, a RESTful API does the same. However, nothing in the REST constraints makes the usage of HTTP as a transfer protocol mandatory. It’s perfectly possible to use other transfer protocols like SNMP, SMTP and others, and your API could still be a RESTful API.
However, in practice, the majority of RESTful APIs currently use HTTP as a transport layer, since the infrastructure, servers and client libraries for HTTP are widely available already.
API Developer Tools – Consider Low-code
Developing, hosting and publishing your own API can be time-consuming and complicated. But this does not mean you can not take advantage of the “API economy”. Many of the new SaaS tools on the market are doing nothing more than assembling REST-based web services into powerful applications. A good low-code platform lets you use that same strategy, or quickly create new business objects that meet your own custom data requirements and validation rules. A common use case is building a low-code application that has some integration with an existing enterprise application or into a new cloud-native application. Using a visual development tool such as Linx that easily consumes those applications via REST APIs is hugely effective in doing so – and quickly.
Further reading: Why low-code and APIs are the perfect match