Open benfrancis opened 6 years ago
I need to address this for my current project. My requirements are:
Since the host portion of the URL implies the gateway, I was thinking of creating a Thing for the gateway device, and then assume that any things on the same host were from that gateway. And then I was going to use the API's in the usual way to interact with the gateway.
But it may be more orthogonal to have a "gateway" object at the root, that has a list of things, which in turn have lists of properties/actions/events. But right now the API is not chatty and nice and simple.
Example from gateway schema being discussed in https://github.com/mozilla-iot/schemas/issues/35
"links": [
{
"rel": "item",
"href": "/things/thing1"
},
{
"rel": "item",
"href": "/things/thing2"
}
]
Questions:
hosts
item
manages
parentOf
gatewayFor
Hmmmm... hosts
kind of makes sense, especially given its intent, but it seems wrong to hijack a term and not use the rest of the spec. For item
, it seems like you're also supposed to use a collection
link in each child to point back to the parent.
If you want to stick with the current naming scheme (even though it's not quite right), you could use thing
. If not, maybe something like child
. Then, each thing could potentially have a gateway
or parent
link.
Generally speaking, the names don't tend to be verbs, so manages
doesn't seem to fit. The names also seem to describe the document that is being linked, rather than the current document, so that cuts out parentOf
.
@mrstegeman wrote:
Hmmmm... hosts kind of makes sense, especially given its intent, but it seems wrong to hijack a term and not use the rest of the spec.
It's very interesting that hosts
comes from the CoRE specification because Michael McCool from Intel today suggested that the Web of Things discovery/directory mechanism defined in the next charter period could be based on CoRE Resource Directories. So maybe we could use the rest of the spec in some way...
Oh I see, RFC 6690 defines its own file format and a /.well-known
URL. We probably don't want to use that. But maybe we can just steal the hosts
link relation :)
I'm actually not opposed to using a /.well-known/thing-description
(or similar) redirect. Those are actually really helpful for other services, e.g. CalDAV.
As suggested in https://github.com/mozilla-iot/gateway/issues/947 we could create a web thing type for Web of Things gateways which includes in its Thing Description links to the things it manages. The gateway web thing type can have actions (such as putting it in pairing mode) and events (such as thingAdded and thingRemoved).
What should this web thing type be called? Is it always a "gateway" (bridging one type of network to another) or is "directory" a better term? (sometimes it may just be a directory of native web things).
Another thing I'm not sure about is whether it's better to have an explicit top level
things
member in the Thing Description, or to add link(s) to thelinks
section with either a single link to a Things Resource or multiple links to individual Thing resources. I suspect using thelinks
member may be easier to get through standardisation than adding a special newthings
member, although we may need to invent another new link relation type for that purpose, e.g.:Creating a
things
link relation would be an obvious addition to the proposedproperties
,actions
andevents
link relations, although to be honest none of these are great link relation names.If each managed thing was provided as a separate link, the existing
item
link relation fromRFC 6573
could be used for this purpose, e.g.:Alternatively, the CoRE (Constrained RESTful Environments) specification (RFC 6690, used by CoAP) specifies a
hosts
link relation type for this purpose, e.g.:This might be something to discuss at the W3C. There's already an example of a
controlledBy
link relation in the Thing Description specification.