APIs’ area of the software world might seem like a huge vital hive because of the dynamic growth and multiplying development paths. From the application architecture standpoint we can observe higher adoption of SOA or microservices approach, also a deeper separation of the client side applications created with modern JavaScript frameworks (Angular, React, Vue) that only communicate with the “back-end” via APIs. We see a high influx of publicly available APIs, API based services or even API as a Service product such as Twilio. Nxt to that, more and more API related products are being created - such as API management platforms, more sophisticated API gateways and so on. We have even started using the “API Economy” term naming the current trend that is inevitably changing the web landscape.
If you run (or planning to) a web-based business, have you ever thought about where are you in this world? Did you evaluate how does your business utilizes the APIs and if you get the maximum value out of it? Or maybe this is too overwhelming, and you do not know where to start? The web world has multiple different API strategies and solutions to offer. So let me introduce you to a few simple concepts that will help you evaluate the APIs usage and their influence on your business.
RESTful, SOAP, RPC, GraphQL - API solutions
Firstly, it’s worth mentioning that there are different types of API, that differ on the level of the technology implementation. Let’s take a look at the most common ones:
- SOAP (Simple Object Access Protocol) - often used in enterprise environments, connecting multiple applications or services, it shines bright when you want to have more control over the communication process and it can use different transport protocols.
- RESTful API (Representational State Transfer) - HTTP communication-based approach, simple, intuitive and light-weight; most commonly used API style of today’s web, especially useful for the publicly exposed APIs
- RPC (Remote Procedure Call) - as a way of invoking actions on another server it can be implemented using different standards such as XML-RPC over HTTP or gRPC using Proto Buffers over HTTP. Such an approach is often used in Microservice architecture.
- GraphQL (Graph Query Language) - the youngest in the group. This approach to API is based on the Facebook’s experience and can come in useful when you have complex sets of data, and you want to retrieve or manipulate only specific parts of the data set effectively.
We or them - who should provide the API?
That was a more technical introduction to the types of APIs that can be implemented in order for applications to communicate between one another. So now let’s turn more to a business perspective. Firstly, we can make a distinction between API’s that we created our own, and the ones that are provided to us by some other organisation(s) - these are the APIs we “consume”.
| OWNED by us | CONSUMED by us | |
| Operations | Creation, documentation, monitoring, maintenance. | Integration, monitoring (to some extent). |
| Control over data provided and structure | Almost always full. | Little to none (suboptimal for us). |
| Multiple sources | Easier to maintain, unify, structure data. | Data mapping/enrichment. |
| Availability | More controllable. | No control at all (downtimes or closure risk). |
| Costs | Investment in development and management. | Access/usage fees may be paid. |
| Resources | Only data and services we have. | Unique data and services or the ones that we do not have. |
Both sides are equally important. Sometimes we have the data and applications in our own ecosystem that we can utilize, but sometimes we need to rely on the 3rd party providers if they have data unique for us, or their services are just cheaper than building our own infrastructure (eg. using Twilio).
What should be really taken into consideration here is the evaluation of the influence of the external API on our system and operations. We should be fully aware of the impact they have on our business, what are the risks related and what will happen if one of such APIs will go down, or what if all of them go down?
On the other hand, we should also be pragmatic in creating and managing our own APIs. Do we actually need all of them, should we manage some specialistic services on our own infrastructure? It’s always worth verifying if there is something we can “outsource” to increase effectiveness and/or reduce costs.
Private, partner or public - choosing the right API access level
Another scope by which we can differentiate the APIs is the access level. In this domain, we can define the private, partner or public APIs.
| PRIVATE | PARTNER | PUBLIC |
| These are the service interfaces used only internally to facilitate the communication between different applications or business domains within our organisation. | Partner API is exposing the data outside of our organisation. But in this case, the access is granted to only selected few. | Public facing APIs are available to all the potential consumers. You still may require a user to have an account in your application, or purchase access to your API, but other than that the access is not strictly limited. |
| Dedicated to address business or technical needs inside the organisation. | Aimed to extend or provide the service/data to the business partner. | Externalizing the data or functionalities to virtually anyone (the access can still be restricted by payment or account) |
What’s the best API set for your project?
Application Programming Interfaces are a real thing, and every modern business has to face them one way or another. Successful companies have to incorporate the APIs as an inherent part of their strategy and not only the tool to achieve certain goals. Otherwise, they will not be able to maximize the value APIs provide them with. APIs should be tailored and exposed to meet every business channel’s requirements and needs. All the contexts (employees, consumers, partners) should be thoroughly considered in digital adaptation.