Introduction
API stands for Application Programmable Interface. APIs function as building blocks that connect apps and systems to one another so they can exchange data. In literal terms, APIs are used to ensure that information may be communicated between two or more systems or services.
(I wrote about APIs and how to get started in an earlier post)
Now what are API styles? These are laid down patterns or conventions that are used for the development of an API. In recent times, there are many technologies available that can be used to design or implement an API, but before you getting started on that, you need to understand the style you want to work with and if it is feasible for the task. I will briefly talk about six API styles in this post.
Tunnel / Web Service Style: SOAP (Simple Object Access Protocol)
This is built on a process of calling functions within a programming language. These functions can be invoked remotely. It uses a message format that is focused on XML (eXtensible Markup Language).
When two applications want to exchange information, SOAP helps to encode this message so it is universally understood.
Advantages are:
〰 Continues RPC line (Corba, COM/DCOM, etc.)
🍖 Good “tooling” for publishers & consumers.
💪 Strong governance model for enterprises.
Limitations: Because it is focused on XML as a message format, this makes it not very flexible. It also ignores a lot of HTTP features like caching.
URI Style: CRUD (Create Read Update Delete)
URI stands for Uniform Resource Identifier. With this design, the API is transformed into a set of resources that support various interactions. Regardless, query parameters and URIs are used to identify and filter requested data.
CRUD interactions are designed to rely on HTTP methods.
Advantages are:
📕 Available knowledge of the HTTP path and query
⌨ Easy to change one element within a complex type
👨💼 It is easy to manage
Limitations: The set of HTTP methods available are very few and URI modelling is not a standard.
Hypermedia Style: REST (Representational State Transfer)
In this API style, the resources are interlinked. Similar to URI style, but it makes use of hypermedia (this includes rich content types, hyperlinks, etc.) to create interactions that are more focused on the task.
I will be talking more about REST in future posts.
Some of it’s advantages are:
⌨ Media types can be customized.
💗 Growing body of guidance (community).
🎗 provides support for long-lasting services.
Limitations: REST can sometimes be assumed to be complex on a large scale.
Event-Driven Style: Reactive
This API style makes use of WebSockets which helps to provide a low-cost method of data transmission between a client and a server.
As new events occur, the client and server keep a watch for them and send asynchronous messages as soon as they do.
GraphQL
An open-source API query language that was developed at Facebook with flexibility in mind for the arguments. Allow consumers to select their preferred method of data delivery.
gRPC
A Google-developed HTTP2-based protocol aimed towards large-scale communication. The message format that enables performance and scaling is agreed upon by the client and server.
Conclusion
There are a lot of resources out there that go in depth for each API Style, feel free to check them out.
If you like this, share it with your friends, and if you have a question, feel free to leave a comment.