Support ID-based HTTP paths for exposed Things

[relu91]

This PR implements support for using Thing id fields to generate HTTP endpoint paths, addressing production concerns with title-based URL derivation. While keeping backward compatibility, it introduces a configurable approach to handle URL path generation.

Problem Statement

As explained in #1458, the current HTTP binding derives endpoint URLs exclusively from Thing titles through slug generation, which creates several issues:

• Multiple Things with identical titles result in unpredictable URL collisions requiring numeric suffixes
• Slug generation is library-dependent, making URLs unreliable across different implementations
• Developers must embed unique identifiers in titles to ensure stable URLs, defeating the purpose of human-readable titles
  Solution

Proposed behaviour:

Introduce a new configuration parameter in HttpServer to use or not the title slugfication to generate Thing paths. For backward compatibility, this feature is true by default. So basically, if the node-wot user wants to have only paths generated with the thing.id, it has to:

• Set devFriendlyUri: false in the HTTP server configuration
• Always provide Things with explicit id values (URN format recommended) -> node-wot will default to title if no id is provided.

Key Changes

• Added devFriendlyUri configuration option to HttpConfig (defaults to true)
• Modified expose() method to support dual-path registration: one from title (when enabled), one from id (when available)
• Both paths route to the same Thing, with proper URL encoding
• Updated destroy() method to clean up both registered paths

Note

Remember that id is optional in Thing Description 1.1, therefore, even with devFriendlyUri set to false, node-wot might generate Things path using the title.