I'd like to summarize the proposals that came up:
1. Change `%1F` to `%2E`:
Already existing namespaces that have the dot-character (`%2E` == `.`)
become inaccessible. A namespace ["my", "elem.foo"] is then encoded as
`my.elem.foo` and decoded as ["my", "elem", "foo"], which is incorrect.
2. New option returned from the config-endpoint telling the which
namespace-element separator to use:
(Old) clients won't respect this option - and in turn, the service has
to expect both `%1F` and the "proposed" separator character. If an old
client sends a namespace element that contains the separator proposed by
the service, the namespace representation on the service side is not the
same as the one on the client side. Ex: A new service advertises `%2E"
via the config endpoint - the old client doesn't know about it and
encodes ["my", "elem", "foo"] as `my%1Felem%1Ffoo`, which the service
either rejects with a HTTP/4xx or interprets as ["my%1Felem%1Ffoo"] -
both are incorrect.
3. Clients send a new query parameter `?delim=.`
(Old) services that don't know about this new query parameter will
interpret the namespace differently, the namespace representation on the
service side is not the same as the one on the client side. A client
encodes a namespace ["my", "elem", "foo"] as `my.elem.foo` and adds the
`?delim=.` query param. Old services interpret this as ["my.elem.foo"],
which is incorrect.
In any case, services _have to_ support `%1F` or compatibility w/ older
clients will be broken.
I do not see any other option than changing the REST spec and define an
escaping mechanism, which requires new endpoints.
All options proposed so far are potentially breaking REST spec changes.
On 05.08.24 19:06, Daniel Weeks wrote:
I would agree with adding either a server side (config override) or
client side control (query param with `?delim=.`) as it will be
compatible with the current v1 endpoint.
In the future we could introduce a v2 endpoint(s), but I would want to
wait for OpenAPI 4 because they address this by allowing multi-segment
pathing via URI templates in RFC 6570
<https://datatracker.ietf.org/doc/html/rfc6570>, which is the original
way we wanted to represent namespaces, but it wasn't supported (e.g.
.../{+namespaces}/tables/{table}). I doubt it's really worth the
effort though, so I feel like a configurable delimiter makes the most
sense.
-Dan
--
Robert Stupp
@snazy
