I think deriving an object’s URL from its title is a problem

[pierre-josselin]

I haven’t found any way to define an object’s URL path other than deriving it from its title, and if that’s really the only option, I think it’s a problem.

I am referring to the mechanism where the title of a Thing Description (e.g. “My counter”) is automatically converted into a URL such as: http://localhost:8080/my-counter

Why is this a problem?

1. Multiple objects could share the same title
   If several objects are created with the same title, it becomes nearly impossible to determine their correct URLs.

   I’ve read that once a slug is generated, if the title is already in use, a suffix (_2, _3, etc.) is appended. However, in a production environment, objects won’t be created manually but imported from a database that may contain thousands of entries.

   If I create 50 objects with the same title, there’s no reliable way to know which URL corresponds to which object, except by relying on the order in which they were created, which is neither practical nor robust.

   Finally, if the order of my objects has changed in my database and I restart the WOT server, my-counter_2 might become my-counter_3

2. Slug generation depends on the tool being used
   slugify is used to transform a title into a human-readable, URL-friendly identifier. If I don’t use the exact same slugification library or rules, I may end up with a different result and won’t be able to access the object.

   For example:
   slugify converts "unicode ♥ is ☢" into "unicode-love-is-radioactive"
   sluga converts "unicode ♥ is ☢" into "unicode-is"

   In this case, even knowing the exact title is not enough to reliably reconstruct the URL if the slugification algorithm differs.

3. Using an unique id in the title defeats the purpose of having a meaningful title
   Indeed, it's possible to use the title to define a unique ID that I know won't be altered by slug (for example, a UUID). That's what I'm currently doing, but I lose the entire advantage of having an explicit and human-readable title, precisely to easily identify my object.

What would be expected?

The object’s URL should use the ID defined in the thing description exactly as-is, rather than derived from the title. The thing description ID would naturally be required to follow a specific format (here an URN) and be guaranteed to be unique.

If no ID is explicitly provided, the system could fall back to the existing behavior and generate the URL from the title using the current slug mechanism.

Conclusion

While this approach may be acceptable for prototyping and experimentation, it becomes a serious limitation in production. When objects are created automatically and in large numbers, the lack of explicit control over URL paths turns into a significant issue, making object identification, access, and long-term maintenance unnecessarily difficult.

[relu91]

Yes, we discussed several times about the best approach to derive the endpoint URI for an exposed thing in HTTP binding. If I recall correctly, we settled down by using the name, as some developers asked for easy-to-type URIs.

The object’s URL should use the ID defined in the thing description exactly as-is, rather than derived from the title. The thing description ID would naturally be required to follow a specific format (here, a URN) and be guaranteed to be unique.

If no ID is explicitly provided, the system could fall back to the existing behavior and generate the URL from the title using the current slug mechanism.

This is not a bad idea. @danielpeintner @egekorkan ?

I was also thinking that maybe we can still generate the slugify URI as an alias to the stable id generated URI.

[egekorkan]

I think relying on the id makes sense too. That is also how it is done in the internal implementation we have