Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thing URL #11

Open
fatadel opened this issue Aug 7, 2020 · 2 comments
Open

Thing URL #11

fatadel opened this issue Aug 7, 2020 · 2 comments

Comments

@fatadel
Copy link
Contributor

fatadel commented Aug 7, 2020

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.

@fatadel
Copy link
Contributor Author

fatadel commented Aug 23, 2020

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.

@fatadel
Copy link
Contributor Author

fatadel commented Aug 23, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant