What the best practices to organize REST API with realtime notification of long operations?
I assume that I can retrieve operationID and then receive real-time operation status through WebSockets.
But which the best option to get results? I guess this is not a good practice to mix notification and retrieving of the result.
Consequently, I need to perform polling or long polling for the results on another endpoint. Is that a good practice?
There is some additional options for long operations:
webhooks(trigger some endpoint when operation was done).push notifications when done(if long-running operation was triggered from client).queues for long-running operations (send message to queue when the operation was done).
It depends on concrete situations. Because your question is general, I also give a general answer: simpler is better.
I guess this is not a good practice to mix notification and retrieving of the result.
I do not see anything not good here, you can use the same channel with format like this for each response:{"status":"in-progress","workload":"72%"} and {"status":"finish","result":"ok"}
If you do not have any obvious reason to use different channels for notification and result, just use a single channel for all kinds of responses.
Consequently, I need to perform polling or long polling for the
results on another endpoint. Is that a good practice?
It's not in real production.
Each long polling is opening a thread on your server, it's cpu intensive.
Long polling handpoints are easy target for various automated DDOS attacks.
The underlying effectiveness of most DDoS attacks comes from the disparity between the amount of resources it takes to launch an attack relative to the amount of resources it takes to absorb or mitigate one. While this is still the case with L7 attacks, the efficiency of affecting both the targeted server and the network requires less total bandwidth to achieve the same disruptive effect; an application layer attack creates more damage with less total bandwidth. https://www.cloudflare.com/learning/ddos/application-layer-ddos-attack/
Your server will be easy to pull down with few malicious connections.
Use a proper wss websockets architecture, full-duplex communication channels over tls encryption, this is the way to go.
It's very efficient regarding data consumption, and power usage overtime. This is to take into account, following my tests, if your clients uses smartphones, the battery really likes websockets over loops of api calls.
Remember, it's still a new born protocol from 2011.
The WebSocket Protocol RFC6455
But our browsers have now sweats reliable and native WebSocket capabilities.
The (javascript) WebSocket API is an advanced technology that makes it possible to open a two-way interactive communication session between the user's browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
Example opening a wss websocket and send some jsonRPC datas from native javascript:
let socket = "wss://echo.websocket.org:443";
let jsonRPC= {
"method": "my_call",
"id": 123
}
Wsock = new WebSocket(socket)
Wsock.onopen = function(event) {
this.onclose = function(event) {
console.log("CLOSED SOCKET")
}
this.onmessage = function(e) {
console.log(e)
}
this.send(JSON.stringify(jsonRPC), function(response){
console.log(response)
});
}Debugger network tab capture with the above script, output 101 Web Socket Protocol Handshake
Based on this
Short-polling vs Long-polling for real time web applications?
: I suggest as Open source long polling solutions:
Go https://github.com/jcuga/golongpoll
PHP: https://github.com/panique/php-long-polling
Node.js: https://github.com/fanout/pollymer
Best practices !
