[PHP] [API] Chapter7: Real-TimeCommunication

[PHP] [API] Chapter7: Real-TimeCommunication in Chapter 6, we learned how to design an API and some Real examples by building our own API. In addition, we have a lot of hard-to-obtain knowledge, and now we can make some achievements. We are ready to witness how to make the API work for us. In this section, we will learn four ways to implement real-time communication through APIs.

Integration

This makes it easier for us to discuss. let's first recall why APIs are useful? Looking back at Chapter 1, we said APIs makes it easy for us to share data between two systems (web pages, computers, and smartphones. Simple Sharing allows us to connect the system together to form an integration. Because integration makes people's life easier, people like integration. Using integration, you can do something on a system. other systems can automatically update and synchronize data.

For our purpose, we split the integration into two directories. First, we should first understand the "customer-driven". people want to influence the client and update the data on the server. The other is called "server-side drive". when people change their servers, they need to let the client know about the changes.

The reason for dividing integration in this way is a simple fact: the client is the only one that can start communication. Remember, when the client sends a request, the server only responds. The consequence of this restriction is that the change can be easily sent from the client to the server, but it is difficult to send 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. Let's talk about a mobile app we released that uses APIs. Here, the pizza shop API is the server, and the mobile app is the client. A customer selects a pizza using the app and clicks the button to send the order. When a button is pressed, the app will know that it needs to send a request to the pizza shop API.

In layman's terms, when a person interacts with the client, the client will know when the data is changed, so it can seek API to let the server know. There is no latency (so it is real-time) and the process is very efficient, because the only request sent by a person.

Server-driven integration

When a pizza order is submitted, the customer may want to know when the pizza is good. How can we provide such updates through APIs? This is a bit difficult. Customers will not do anything to make pizza. They will only wait at the pizza shop to prepare the pizza and update the order status. In other words, when the data is being changed on the server, the client needs to know about them. However, if my client cannot send a request, we will get stuck.

The solution to this problem is to use the second integrated directory. Software developers in need come up with various solutions to overcome the limitation of client requests. Let's take a look.

Round Robin

Although the client is the only one that can send requests, the simplest solution is to keep the server updated when the client needs updates from the server. This can be done by repeatedly requesting the same resource, called polling.

When a pizza shop polls an order, the status may be the same as the following:

In this way, the more requests the client sends, the closer the client gets to real-time communication. If the client does not perform one-hour round-robin, the worst result is that there will be an hour of delay. the client will detect the delay when the server changes. Polling every minute, the server can effectively maintain synchronization.

Of course, this method has a huge defect. This is very inefficient. Most of the requests sent by the client are wasted because there is no change. What's worse, the polling interval needs to be very short for faster updates. in order to make the client send more requests, it becomes increasingly inefficient. This method is difficult to expand.

Long polling

If the request is free, no one cares about efficiency, and everyone uses round robin. However, unfortunately, it takes some time to process the request. For an API that requests more requests, it requires more services and more money. This level of complexity can reach the ratio of Google to Facebook, and you have paid a lot of inefficiency. Therefore, a lot of effort is invested in optimizing this method, and the client obtains updates from the server.

Optimized from polling, called Long polling. In the same way as long polling, the client repeatedly asks the server for updates, but the difference is that the server does not respond immediately. On the contrary, when the server changes, it will respond to the update.

Let's recall the round-robin example, but this time the server uses a long round-robin.

This technology is very clever. It follows the initial request rules of the client and uses the rules that do not oppose slow responses from the server. As long as the client and the server agree, the server can hold the client request, and the client can maintain a connection with the server, it will work.

Long polling is very intelligent and has some disadvantages. We jumped to the technical details, but there will be some attention, how many requests can be held by the server at the same time, or how to restore if the server and the client are disconnected? Now, we will say that in some cases, the round robin method is not enough.

Network connection

When polling is ruled out, some innovative software developers think, "if all the problems come from the fact that the client is the only one that can send requests, why not remove this rule ?" As he said. This result is webhocks, a technology that allows clients to send requests and listen to them, so that the server can easily push updates to it.

If this sounds like a scam, because we have the server send a request to the client, don't worry, you are not cheated. Changing the client to a server can cause network connection. By looking at this technology, sometimes it can easily expand the client so that it can also hear requests and enable two communication methods.

Let's take a look at the basics of network connection. In the simplest form, the client needs to provide a Callback URL to receive the event, and the server has a place where people can access Callback. Then, once the server changes, the server sends a request to the client's Callback URL to let the client know the update.

Compared with our pizza shop, the process may look like the following.

This solution is very good. The change is sent to the client immediately on the server end, so you have real-time communication. In addition, network connection is also very efficient, because each update only has one request.

Subscription network connection

On the basis of network connection, a large number of solutions have emerged to make the creation process dynamic and do not need to manually enter the Callback URL on the server. You may have heard about the HTTP subscription specification, Restful Webhooks, REST Hooks, and PubSubHubbub. All these solutions are to determine a subscription process. The client tells the server what events it is interested in and what updates the Callback URL sends.

Each solution is slightly different to solve the problem, but the general process is the same as below.

Subscription-based network connections have many commitments. They are efficient, real-time, and easy to use. Similar to the adoption of REST, a wave is emerging and becoming more and more common. APIs support some network-mounted forms.

Still, in the future, this part will be round robin and long polling. Not all clients can act like clients. Smart phones are the best example. technical restrictions exclude the network connection method. As technology advances, new methods will emerge, making real-time communication easier across all devices.

Chapter 7 summary

In this chapter, we divide the integration into two directories: Client-side driver and server-side driver. We understand how APIs provide implementation updates between two systems, and some problems exist.

Key points:

• Poling: repeatedly requesting resources within a very short period of time

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

• Webhooks: when the client sends a Callback URL to the server, the server can provide real-time updates.

• Subscribe Webhooks (Subscription network connection): informal solution name for automatic network connection