For example, every time I type characters such as Google Suggest, I communicate with the server (HTTP request), but
Communication (HTTP request) is asynchronous, so we will make a new request without receiving the previous response.
At this time, I don't need any requests that haven't been returned, but should I abort them?
Or is it okay to leave it alone?
Which implementation would be better for the client side?network http asynchronous
As you mentioned in the example, it will eventually depend on the implementation.
The timing of communicating with the server is probably not immediately done for Key related events, but every second, etc. (otherwise, it's too much of a load to waste).
Also, I think that the server also processes the data received by rounding it up every second, so there is no big difference whether it is left unattended or cancelled.
"However, I think it would be better to leave ""2"" in the case of limiting the processing on the server side to something that ends in an instant, and implementing it as you dare."
The reason for this is that the heaviest processing of HTTP API communications is the processing of HTTP requests themselves, so sending a cancellation request is often more processing-intensive.
The API generalization should be that if the provider wants to complete the request properly or cancel the unnecessary request, there should be a mechanism to cancel it.On the other hand, if there is no cancellation mechanism, users can't do anything about it.
The web API that repeats simple requests/responses is definitely the latter, but there may be heavy processing (response takes a long time) or cancellation if there is a condition.
Therefore, you should first check the API specifications rather than the cost.
© 2022 OneMinuteCode. All rights reserved.