Multiple things per WebSocket about api

[benfrancis]

Note that the W3C spec already has an id member for a Thing which is a URI identifying the Thing. This can optionally be the URL of the Thing Description.

See also: #29

[benfrancis]

I agree it should be possible to have multiple things per WebSocket, as you say we just need to provide a thing ID (URI) in each message to indicate which thing it refers to.

[YonasJ]

I would like to bump this idea.

When implementing the API using the arduino API's for the ESP32 I have encountered some challenges:

• The API's don't really support handling the websockets dynamically. So, it is a fair bit of extra coding to create an end point for each URL.
• Each websocket uses a fair amount of the precious memory available.
• I had to do a lot of duplication to support the HTTP and WebSocket API.

I will put some comments in "Implement a single Websocket endpoint for things #947" as well.

[benfrancis]

Proposal: Add an id field to WebSocket messages whose value is a URI identifying the thing the message relates to.

{
  "id": "http://mythingserver.com/things/robot1"
  "messageType": "setProperty",
  "data": {
    "leftMotor": 100
  }
}

We also need to figure out how to expose the WebSocket endpoint as currently we do this in the links member of a Thing resource which corresponds to a single Thing.

Perhaps if there is a Gateway capability the Thing Description for the gateway itself can have a top level links member which can link to a WebSocket endpoint for the whole gateway.

[hobinjk]

As per the meeting today, this should come with a section or equivalent note that opening a websocket on /things will make a websocket corresponding to multiple things.

This could be considered part of a Gateway capability