You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Create Thing and expose it within the following URL: scheme://ip-address:port/thing-title, e.g. http://127.0.0.1:8080/Smart-Coffee-Machine
which looks pretty concise.
wot-py approach:
Create Thing and expose it within the following URL: scheme://hostname.domain:port/thing-id+uuid(derived from TD), e.g. http://my-hostname.my-domain:9090/urn-dev-wot-example-coffee-machine-97e83de1-f5c9-a4a0-23b6-be918d3a22ca
which is imho too long and quite overwhelmed.
The text was updated successfully, but these errors were encountered:
I've realized that it is actually not thing-id+uuid but thing-name+uuid.
Nevertheless, I don't see any reasons to have the uuid in URLs.
If you expose two different Things on the same port it doesn't work anyway and only one of them is indeed being exposed.
So, there is no possibility for name collisions, and thus for unique ids (uuid) in URLs.
I've pushed a PR (#15) which partly closes this issue.
The remaining part is the difference in hostname generation.
node-wot collects IPs from all network interfaces and binds the Thing to all of them.
On the other hand, wot-py uses FQDN as the default hostname and only one (primary) IP-address if no FQDN is found.
node-wot approach:
Create Thing and expose it within the following URL:
scheme://ip-address:port/thing-title
, e.g.http://127.0.0.1:8080/Smart-Coffee-Machine
which looks pretty concise.
wot-py approach:
Create Thing and expose it within the following URL:
scheme://hostname.domain:port/thing-id+uuid(derived from TD)
, e.g.http://my-hostname.my-domain:9090/urn-dev-wot-example-coffee-machine-97e83de1-f5c9-a4a0-23b6-be918d3a22ca
which is imho too long and quite overwhelmed.
The text was updated successfully, but these errors were encountered: