This can be a complex topic if you don’t set clear constraints on what constitutes a valid character in your URL or domain.
For instance, in query parameters, spaces are encoded as '+'. But what if '+' is also a valid character in your domain? You then need to disambiguate i.e between "name?foo+bar" meaning "foo bar" or "foo+bar". Which one is the user actually referring to?
In our case, we ended up needing users to send the name in the body, and now we have to manage multiple encoding protocols (url, queryparam, the body...).
A user might have entities named "foo bar", "foo%20bar", and "foo%2520bar". Sometimes, mistakes happened because users forgot to double encode or they used the wrong protocol. As this names were used in URL, query parameters, and the body, and each has its own.
As I mentioned, with clear constraints and rules, we can accomplish anything we need, it can get complex. My takeaway from this project is to limit the valid characters and make it simple for everyone.
Actually, not encoded slashes in the paths are not that unheard of as one might think. As an example, this is actual Wikipedia article about... the meaning of "two slashes": https://en.wikipedia.org/wiki/// . Also, encountering buggy concatenations like example.com//some-path or example.com/base//some-path is quite common.
Do path parameters get to have / in their values?
Let’s say you have a link shortener service and want to allow users to define shortcuts like /mypath/:rest where rest is appended to example.com/
Now you’re in a very interesting position when it comes to resolving URLs.
Curious to hear folks with experience in this