spec: use URL patterns instead of URI templates

[dunglas]

The URL Pattern standard has finally been published. This is great news for Mercure, as it was the only missing part to publish a definitive version of the protocol, and a version 1.0 of the hub.

Until now, we've allowed multiple resources to be selected to subscribe to notifications using URI patterns (RFC 6570). This approach works, but has a few drawbacks:

1. As stated in the URI Templates (RFC 6570) specification, URI templates are not designed for matching:

Some URI Templates can be used in reverse for the purpose of variable matching: comparing the template to a fully formed URI in order to extract the variable parts from that URI and assign them to the named variables. Variable matching only works well if the template expressions are delimited by the beginning or end of the URI or by characters that cannot be part of the expansion, such as reserved characters surrounding a simple string expression. In general, regular expression languages are better suited for variable matching.

2. Matching with URI Templates is more limited than with regular expressions.
3. The syntax of URI Templates, especially when used for matching, is not very popular and most web developers have difficulty mastering it. This is a problem regularly encountered by Mercury users. We've even created a tool to help them: https://uri-template-tester.mercure.rocks. Regular expression syntax is much more popular.

This (hopefully last) change in the specification replaces usage or URI Templates by URL patterns for subscribing to several topics at the same time.

I've also taken the opportunity to separate the comparison of raw topics (exact comparison) from the comparison with URL patterns. The topic query parameter is still used for raw string comparison, but a new pattern query parameter is used for URL templates. In addition, support for pattern comparison by hubs is now optional, facilitating protocol implementation.
This change simplifies the implementation of the specification, and makes it possible to switch from URI patterns to URL patterns (a hub will be able to support both obsolete patterns and new ones). This is important, as Mercury is now very popular.

@wanderview, as the lead author of the URL Pattern standard, I wonder if you could verify that we are using the standard as intended.

For #588.

Next steps:

• write an implementation of URL Pattern in Go (work in progress)
• patch the hub to implement this change using this new library

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.