Lexical restrictions on names/ids used in the URI path?

[cportele]

(Moved from a discussion on Gitter)

Should we restrict the lexical space of names/ids used that are used in the URI path? For example the {collectionId} and the {featureId}?

Technically RFC 3986 supports also reserved characters - these have to be percent encoded. But in practice this may cause issues due to different software tools handling this differently. So maybe we should restrict them to the characters that are unreserved in RFC 3986:

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

The following characters do not have to be percent encoded and could also be allowed, but maybe this is unnecessary?

"!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" / "@" / ":"

[aaime]

My 2 cents would be not to place more restrictions compared to general web rules. At the same time, adding an example or a warning in the spec or guide about it could be useful to many.

[cportele]

Maybe a recommendation with an example?

[cmheazel]

The OpenAPI Server Object allows you to specify valid values to use in the URL template for the host. Would a similar capability be useful for Paths? This would allow you to apply restrictions on individual template variables.

[cholmes]

I'm in favor of restrictions here - would just do unreserved. Percent encodings can lead to urls that are just not so sensible. @m-mohr just gave an example in gitter of /collections/%E6%BC%A2%E5%AD%97/items (the encoded chars are actually 漢字).

I think server implementations can translate from different inputs to match the rules. I think of 'name' more like 'id' (indeed I'd say we could even consider changing it to id - we do call it {collectionId}).

[cportele]

15-April-2019 Teleconference: Do not restrict what is allowed for URIs, but highlight that any reserved character must be percent encoded.