Learn more >
by Callum Jackson | Published June 13, 2019
APIs (application programming interfaces) have existed since the beginning of computers, but as the Web became ubiquitous, APIs have been repurposed to refer to HTTP REST-based services. REST (representational state transfer) is a commonly used concept that provides access to resources using standard HTTP operations such as GET, PUT, POST, or DELETE. For example, a system can request information regarding a book by sending the following request:
In this example the GET operation is used to declare that we are attempting to read the current state. The URL http://mybookstore/books/mybook is then used to identify the resource to be retrieved. The following figure shows a basic REST API.
Messaging encourages a decoupled architecture, where an intermediary – often referred to as a messaging provider – is placed between two applications, systems, or services. The messaging provider facilitates communication between the sender and receiver of messages and provides many benefits such as reliable delivery, work load balancing, and security.
Some examples of messaging providers include:
A messaging client is used to communicate with a messaging provider. A client can take the role of either or both of these:
Requesting services publish (PUT in REST terminology) a message to request processing, while the providing service subscribes (GET in REST terminology) to the message to complete the processing.
APIs and Messaging are widely used technologies, both individually and together. The key to success is understanding their characteristics so that you can select the right option based on the communication requirements:
To help you decide whether to use APIs or messaging, let’s consider three different scenarios.
In the first scenario, a retailer exposes their product catalogue. By exposing their product catalog, a partner can quickly and easily access it on their own. The data in the catalog is read-only, so users can repeat requests in error situations. The simple and synchronous characteristics of RESTful APIs make this a natural choice.
In the second scenario, a healthcare provider updates a patient’s record after they treat the patient. The health data represents a mission-critical communication to both the healthcare provider and the patient. The assure messages are not lost characteristic of messaging is valuable here.
In the final scenario, let’s consider a retailer’s digital transformation. The retailers can build new engaging applications which can allow partners to sell their products. Access to the catalogue and ordering systems is required. In this situation, a combination of APIs and messaging is logical. Where simple and synchronous is important, the catalog is exposed, using APIs, and messaging provides access to the order system to assure that messages are not lost and decoupling to handle peak workloads.
Deciding between implementing your solution with APIs or messaging is not an either/or decision; sometimes your solutions will require both. Both APIs and messaging provide many benefits to developing robust, engaging apps.
Use a Node.js proxy to inspect external APIs.
This article takes a closer look at one of the most common patterns for building an event-driven solution and gives…
Apache KafkaAPI Management+
Back to top