Use of REST API over WebSocket

[JoobyPM]

It will be a super cool feature to make accessible REST API over WebSocket.

I understand that between servers, we are using high-speed broadband, but after working with LoraWan I redefined use of the resource in a more sustainable manner. Just think about use case when we are using REST API over HTTP - each time client or server sends some request for REST API, on transport level generated a bunch of overheads, that can be avoided if an option going to be available to work with REST API over WebSocket.

Same payload format, but with aditional "transport level envelope", for example request might looks like:

{
"uri":"api/rxframes?_filters={\"devaddr\":\"00000004\"}",
"method":"GET",
"headers":["{key}:{value}","{key}:{value}"]
}

and acknowlegment from NS, might looks like:

{
"uri":"api/rxframes?_filters={\"devaddr\":\"00000004\"}",
"method":"GET",
"status":200,
"headers":["Content-Type: application/json"],
"body":"[]"
}

headers might be an optional.

[gotthardp]

In HTTP you can open one connection and then generate multiple requests. Do you really see that much overhead?

[JoobyPM]

It depends on use cases. But with WebSocket, you got flexibility and real-time communication without overheads. A least for those who use WebSocket, they can consolidate communication with the server over one* connection, it's mean twice fewer overheads and one technology (one type of auth, one logic, real-time, HTTP REST as a back up).