• APIs vs. WebSockets vs. WebHooks: What to Choose?
  • Original post by Chameera Dulanga
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: Hoarfroster
  • Proofreader: Chorer, HumanBeingXenon, Usualminds

No matter what application we develop, we need a reliable mechanism to communicate between components.

For example, in a Web application, we need to communicate between the browser and the server; Sometimes the server needs to send messages back to the browser; In addition, in some cases, a back-end service may depend on another service that requires a very long response time.

This is where apis, WebSockets, and WebHooks come in. They provide the perfect solution to this problem, allowing us to communicate and synchronize data between different modules of the application.

Although all three methods are primarily used for communication, there are some obvious differences between them. In this article, we’ll discuss how to use these three apis and how to choose the most appropriate approach depending on your usage scenario.

API – Provides interfaces and protocols to users.

An API (application program Interface) is a protocol between a user and a service provider, usually exposed in HTTP requests.

This approach works well for basic CRUD operations on the Web and mobile devices, even in scenarios where integrated services access other services. In most cases, API communication uses JSON or XML as the format for transferring data.

Let’s imagine a scenario where a user searches for an item on an e-commerce site. Once a user requests the item he or she is looking for using a search query, he or she gets a response within seconds. That’s how apis work.

As I mentioned initially, API requests are user-initiated, so they are ideal for applications that persist and perform fast operations to receive real-time responses from back-end operations.

With apis, however, there is no direct way for the server to actively communicate with the browser unless the browser periodically sends requests to check for updates.

For example, tasks such as report generation can take more time and resources, which typically need to be done in the background. So when a user requests a service provider to generate a report, the server has no direct way to tell the user that the task is complete, and our browser may need to continually poll the API.

But polling is inefficient, and there are better ways (such as WebSockets) to solve this problem.

WebSockets — a solution for real-time communication

** WebSockets solve this problem by allowing persistent two-way communication between the user and the service provider. **

Using a full-duplex channel allows the server to send messages to the user at any time. Since all modern browsers support WebSockets, it is arguably the best solution for real-time Web application scenarios.

However, keeping the connection open consumes resources, affects power consumption (on mobile devices), and makes it difficult to scale services.

For example, considering the reporting scenario above, using WebSockets on the Web might be a good option, but not the best option for mobile devices, where we might need to explore technologies like push notifications. Also, if our back end relies on external services to generate reports, WebSockets are not the best choice for the back end to communicate with external services.

This is where mechanisms like WebHooks come in handy.

WebHooks – Perfect back-end callback solution

WebHooks provide a solution to the thorny WebSockets problem by providing a disconnect mechanism to receive responses from the service provider.

If, technically, the user registers WebHooks (callback URLS, to be exact) with the service provider, that URL acts as the place to receive data from WebHooks.

In most cases, this URL belongs to another server. WebHooks are typically used to communicate between server or back-end processes.

If we delve into the process of communication, we can divide the process into four parts:

  • Event trigger: This is the event that you specify to run WebHooks. WebHooks send the request each time this event occurs.
  • The WebHooks provider creates WebHooks and sends POST requests: The WebHooks provider listens for events and builds WebHooks. Once the event is triggered, the WebHooks provider sends an HTTP POST request to the third-party application.
  • Third party application receives data: The third party application receives data and forwards it to the URL or to the listener we provide to the WebHooks provider.
  • Actions specified in third-party applications: Once the application receives a POST request, the developer is free to use the data at will.

On the face of it, we might all think that this is the opposite of API flow, so most people refer to WebHooks as reverse apis.

conclusion

As I mentioned initially, WebHooks, WebSockets, and apis can all be used for communication, but they have different usage scenarios.

For applications that require only basic CRUD operations and synchronized responses, apis are the best choice. Furthermore, the API can be easily used with Web and mobile applications and service integration.

However, if our Web application needs to communicate with the back end in real time, WebSockets should be preferred because they allow us to establish a bidirectional channel between the browser and the back end.

However, WebHooks are a little different from apis and WebSockets in that they are more like reverse apis. Once the user registers the WebHooks URL with the service provider, the service provider can invoke WebHooks when needed.

Now that you’ve seen how these communication methods are used in different ways, if you have something you’d like to share, please leave it in the comments section.

Thanks for reading!

  • This article is participating in the “Nuggets 2021 Spring Recruitment Campaign”, click to see the details of the campaign

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.