[PHP] [API] Chapter 7:real-time Communication

In the sixth chapter, we learned about the design API and some real-world examples by building our own API. In addition, we have a lot of hard-earned knowledge, and now we can make a difference. We are ready to witness how the API works for us. In this chapter, we learn 4 ways to implement real-time communication through the API.

Integration

Let's make it easier to talk, let's recall why the API is useful? Recalling the first chapter, we say that APIs make it easy to share data between two systems (Web, computer, smartphone). Simple sharing allows us to connect systems together to form an integration. Because integration makes life easier for people, people like integration. With integration, you do something on one system, and other systems can automatically update the synchronization.

For our purposes, we will divide the integration into two directories, first of all, we first understand "customer-driven", people want to affect the client, and let the service side of the data update. Another one we call "server-side drivers", when people change in servers, need to let the client know about the changes.

The reason for partitioning the integration in this way is a simple fact: the client is the only one that can initiate the communication. Keep in mind that the client makes the request and the server just responds. The consequence of this limitation is that the change can easily be sent from the client to the server, but it is difficult to send it from the server to the client.

Customer-driven integration

To demonstrate why customer-driven integration is easy, let's go back to the pizza shop and ordering API we talked about earlier. Say a mobile app that we publish using the API. In this, the pizza shop API is the server, the mobile app is the client. A customer uses the app to select a pizza and click the button to send an order. When the button is pressed, the app knows it needs to send a request to the pizza store API.

In layman's words, when a person interacts with the client, the client knows when the data is changed, so it can look for APIs to let the server know. There is no delay (so it is real-time) and the process is very efficient, because only one request is made by the person.

Server-driven integration

When the pizza order is submitted, the customer may want to know when the pizza is good. How do we provide them with this update through the API? It's a little hard. Customers don't do anything for pizza making. They just wait at the pizza shop to prepare the pizza and update the status of the order. In other words, when the data is changing on the server side, the client needs to know about them. However, if my client cannot make the request, we are stuck.

The solution to this problem is that we take advantage of the second integrated directory. The required software developers come up with a variety of solutions to overcome the limitations of only client requests. Let's take a look.

Polling

Although the client is the only one that can send the request, the simplest solution is to keep the server update, when the client needs the service-side update. This can be done by repeatedly requesting the same resources, called polling.

When we have a pizzeria, the status of polling an order may be the same as the following:

In this way, the more frequently the client sends the request, the closer the client is to real-time communication. If the client does not poll for one hours, the worst result is that it will have a one-hour delay, which the client is aware of when a change occurs on the server. Polling every minute, the server can effectively stay in sync.

Of course, there is a huge flaw in this approach. This is very inefficient. Most of the requests sent by clients are wasted because there is no change. To make things worse, the polling interval needs to be short for faster updates, making it increasingly inefficient for clients to send more requests. This approach is difficult to expand.

Long polling

If the request is free, no one cares about efficiency, and everyone uses polling. Unfortunately, there is a cost to handling the request. For an API that requests more requests, it needs to use more services and spend more money. This can be as big as Google and Facebook, and you're paying a lot of inefficiencies. Therefore, a great deal of effort is devoted to optimizing this approach, and the client gets updates from the server.

From Samsara is optimized for polling, called Long polling. Long polling uses the same idea that the client repeatedly asks for server updates, but the difference is that the server does not respond immediately. Conversely, updates are not answered until the server has changed.

Let's recall the polling example, but this time the server uses a long polling.

This technique is very clever. It follows the rules of the client's initial request, with no rules against a slow response from the server. As long as the client and server agree, the server can hold the client's request, and the client can maintain the connection with the server, it works.

Long polling is very intelligent, and it has some drawbacks. We jumped over the technical details, but there are some concerns about how many request services can be held at the same time, or if the server and client are disconnected, how can I recover? Now, we would say that in some cases, polling is not enough.

Network Hook-up

When polling is excluded, some innovative software developers think, "if all the problems originate from the client being the only one that can make the request, why not remove the rule?" "As he has said. The result is a network hook-up (webhocks), a technology where clients can send requests and listen to them, allowing the server to easily push updates to it.

If this sounds like cheating, because we let the server send the request to the client, don't worry, you are not cheated. Let the client also become the server to let the network hook up work. With this technique in perspective, it is sometimes easy to extend the client so that it can hear the request and enable both modes of communication.

Let's take a look at the basics of network hooking up. In its simplest form, a network hook requires the client to provide a Callback URL (callback URL), to accept events, and to have a place on the server where people can enter Callback. After that, once the server has changed, the server sends a request to the client's Callback URL to let the client know about the update.

In contrast to our pizza shop, the process may look like this.

This solution is very good. Changes are sent to the client at the end of the service, so you have real real-time communication. In addition, network hooking is very efficient because there is only one request for each update.

Subscribing to a network hook up

On the basis of network hooking up, a lot of solutions emerge to make the establishment process become dynamic and do not need people to manually enter the Callback URL on the server side. You may have heard the HTTP subscription specification, restful Webhooks, REST Hooks, and Pubsubhubbub. All of these workarounds are attempts to determine a subscription process, which the client tells the server what events it is interested in, and what updates the Callback URL sends.

Each scenario is slightly different and solves the problem, but the approximate process is the same as the following.

Subscription-based network hooking holds many commitments. They are efficient, real-time, and people can easily use them. Like REST is adopted, a wave is rising and becoming more common, for the API supports some form of network hooking up.

Still, in the future, this will be part of polling and long polling. Not all clients can act as if they were clients. Smartphones are the best examples, and technical limitations preclude the way the network hooks up. As technology advances, new approaches emerge that make real-time communications easier across all devices.

Seventh Chapter Summary

In this chapter, we divide the integration into two directories, client-driven, and server-driven. We understand how the API provides implementation updates between the two systems, and there are some issues.

Key points:

• Poling (polling): repeatedly requesting resources in a very short period of time

• Long Poling (polling): polling, but response delay; improved efficiency

• Webhooks (Network Hook): When the client gives the server a Callback URL, the server can provide updates in real time

• Subscription Webhooks (subscription network hook): An automated, informal solution name for network hook-up

