eclipse-thingweb
What is the best way to create URLs for hosted things
Based on https://github.com/eclipse-thingweb/node-wot/issues/1351 and the proposed PRs (https://github.com/eclipse-thingweb/node-wot/pull/1352 & https://github.com/eclipse-thingweb/node-wot/pull/1375) to fix name clashes a more general question arose.
What is the best way to generate URLs for hosted things?
At the moment, we use slugify to create human-readable URLs based on the given name of a thing.
In the case of name clashes, we add a suffix like _2 to differentiate them.
In the case of many sensors with the same name, these artifacts might happen very often...
In a discussion with @relu91 we also talked about using the given id or create UUIDs if the id is not given. Unfortunately this make it hard to predict URLs like we do in some examples (causes problems for humans)
Having said that, I think we need a more general discussion how URLs should look like and whether they might differ depending on the protocol.
Feel free to comment and share you view!
I'm looking forward to knowing how @RobWin, @lu-zero, and @benfrancis handle this.
It is also related to yesterday's discussion about what we can describe in a protocol binding template. Maybe a profile would prescribe how it must generate end points for "greenfield" devices (Current document for HTTP basic profile does not say anything about it). Even though I'm questioning if defining a definitive URI structure would create some anti-patterns, like trying to discover/fetch things by appending ID/title or whatever we decide.
In WebThings Gateway each adapter add-on is responsible for its own namespace. Each add-on has a prefix (e.g. "zb" for Zigbee) and then the add-on generates its own ID for each device, which could be random, it could be an auto-incremented number, or it could be based on a physical ID such as digits from a MAC address. For example, the Virtual Things add-on generates IDs like https://demo.webthings.io/things/virtual-things-20.
I don't see any reason for Profiles to enforce URL structures for anything, like you say it could introduce anti-patterns where a certain structure is assumed. Thing Description URLs are discovered using discovery mechanisms and endpoints for interaction affordances are discovered via Forms in Thing Descriptions.
I have no comment about non-web protocols 🙊
I would simply use their hardware/unique identifier as root/namespace it is a good idea to add a demo for it in general.
