Same href for all Forms

[egekorkan]

Having href in a form definition and in none of the forms in the compact TD would be relevant for protocols where the resource is not defined in href. WebThing WS subprotocol is one such example.

Relevant issues:

• href in formDefinitions  #2176
• Extending Common Definitions Proposal from CG Participants' Input #2153 (comment)

For the record, we did decide that all protocols should use href to identify the resource. Even in WebThing WS subprotocol, there is the notion of a resource, which is just the affordance name in the json payload sent but it is not formalized as an href

[egekorkan]

TD Call: We will leave it open for now and discuss it when we have more connection oriented protocol examples. It doesn't have a big impact on the proposal itself.

[benfrancis]

Having href in a form definition and in none of the forms in the compact TD would be relevant for protocols where the resource is not defined in href. WebThing WS subprotocol is one such example.

Minor point, but in the Web Thing Protocol WebSocket sub-protocol it is possible for every Interaction Affordance to have a different href, it's just less efficient because the specification basically says that if the href is the same as an existing connection that connection can be reused. The recommended approach would indeed be to share the same connection for all affordances of a Thing (treating the Thing as just one resource), so in that case it would save some bytes to define a shared href in formDefinitions or formDefaults. It may still be useful to override Forms with different values for op.

It looks like in the examples I gave in #2165 (comment) I already assumed that href was optional in Forms if it was set in defaultForms.

For the record, we did decide that all protocols should use href to identify the resource. Even in WebThing WS subprotocol, there is the notion of a resource, which is just the affordance name in the json payload sent but it is not formalized as an href

I think that's a bit of a generous stretch 😂 I don't think the Web Thing Protocol WebSocket Sub-protocol is particularly resource orientated or RESTful, which is something I don't love about it. But opening a separate WebSocket connection for every InteractionAffordance of every Thing is just not an efficient way of using WebSockets, and negates most of the benefits of using a bi-directional persistent connection.*

(In the legacy Web Thing WebSocket API a single shared WebSocket endpoint is provided in a top level Link of a Web Thing Description.)

---

*I can imagine a URL structure where properties, actions and events are identified in separate URLs after a # symbol (but the connection can still be re-used), but I can't really think of any benefits of doing that...

[relu91]

I can imagine a URL structure where properties, actions and events are identified in separate URLs after a # symbol (but the connection can still be re-used), but I can't really think of any benefits of doing that...

That's more or less what has been discussed for the MQTT binding. As stated in the call, we have to question ourselves if Affordance = Web resource is valid for all the protocols we want to support. I agree that trying to stretch the concept to fit "messages" or "topics" might not be the intuitive or correct approach, but changing this implies a relevant architectural shift for WoT.

Regarding the discussion about connection, I don't think it is really impacted by the choices above. It's a client implementation strategy much like a browser can decide to open N tpc connections for each resource or keep one tpc connection open and get back a bunch of resources.

[egekorkan]

As stated in the call, we have to question ourselves if Affordance = Web resource is valid for all the protocols we want to support.

While correct, I want to make sure everyone understands the same thing:

• There should be a single connection opened for MQTT, WS, etc., regardless of the number of operations done on the affordances.
• The notion of resource is not necessarily a string (URI to be specific) in different protocols, but it always exists. We have to decide whether a resource should be
• The URI used to open the WS connection is NOT a resource from my point of view. Same for MQTT. Broker URI is NOT a resource. Therefore, these URIs are not enough to identify the resource. Ideally, there should be a URI scheme including the resource even for subprotocols, but that is a wish that is difficult to fulfill.

[benfrancis]

@relu91 wrote:

As stated in the call, we have to question ourselves if Affordance = Web resource is valid for all the protocols we want to support. I agree that trying to stretch the concept to fit "messages" or "topics" might not be the intuitive or correct approach, but changing this implies a relevant architectural shift for WoT.

I think the problem here is, and always has been, trying to use the Web of Things to describe non-web protocols (and for the record I think it could be argued that WebSockets falls into that category). Hypermedia controls like "forms" are designed to be used with a RESTful architecture, which most existing IoT protocols simply don't adhere to.

@egekorkan wrote:

The URI used to open the WS connection is NOT a resource from my point of view.

I think a WebSocket endpoint is a resource that can be linked to, but it does not resolve to a representation of the resource, it resolves to a connection over which operations can be carried out on the resource (the resource in this case usually being a Thing). FWIW this is why Mozilla's legacy Web Thing Description uses a top level link to link to a single WebSocket endpoint, rather than a form to describe each operation.

Unfortunately trying to retrofit a URI scheme onto an existing protocol which is not inherently resource orientated does not make it RESTful, so protocol bindings have to rely on semantic context extensions to fully describe operations in those protocols (unless using a prescriptive sub protocol). The value of href may always be the same in connection-orientated protocols because there is only one resource, but the individual operations are described using protocol-specific semantics.

If Thing Descriptions are to continue to be used to describe non-web, connection-orientated protocols then I think it has to be expected that href may be the same for all forms, and therefore it makes sense that href could be one of the defaults set in formDefaults (or formDefinitions).