In any event, as far as I can tell this is a unique design, so maybe it’s too weird or not properly RESTful? Would love to know of any other patterns designed to solve the problem of supporting arbitrarily-named secondary unique keys. What do you think?
Not that unique. 🙂 And it really has nothing to do with representational state transfer.
This is purely URL design (i.e. purely a server-side concern). So on that note, let’s take a look at the good RFC:
Aside from dot-segments in hierarchical paths, a path segment is considered opaque by the generic syntax. URI-producing applications often use the reserved characters allowed in a segment to delimit scheme-specific or dereference-handler-specific subcomponents. For example, the semicolon (";") and equals ("=") reserved characters are often used to delimit parameters and parameter values applicable to that segment. The comma (",") reserved character is often used for similar purposes. For example, one URI producer might use a segment such as "name;v=1.1" to indicate a reference to version 1.1 of "name", whereas another might use a segment such as "name,1.1" to indicate the same. Parameter types may be defined by scheme-specific semantics, but in most cases the syntax of a parameter is specific to the implementation of the URI's dereferencing algorithm.
So the premise of your design is sound – sound enough, in fact, to show up all the way back in the RFC. 🙂
I would just have used different syntax to match RFC-suggested convention, namely /users/;username={username}
.
Note that the parametrization this section talks about is “applicable to that segment”, which is to say that if you want, it naturally expands to support, in your example, things like /users/;username={username}/profile
.
It plays the role of not just the
&
in the query parameters but also the?
. It’s a marker that the segment is parametrized in some way in the first place. Without any;
present, the=
is just part of the name of the path segment, similar to a query without a?
.Exactly, the equals sign needs the semicolon in order to work.
One more reason not to which I’ve not brought up so far is that among reserved characters,
:
is in the gen-delims set whereas;
and=
(and also,
) are only in the sub-delims. One of the consequences section 3.3 on paths cites isAdmittedly it’s more of a congealed gut sense over time since I no longer remember the individual cases, but occasionally hitting cases where colons had to be encoded or cases where URI code just chose to encode most colons (which per section 2.2 on reserved characters is a perfectly reasonable way to deal with the gen-delims set) has left me with a vague iffiness about the colon as syntax in URLs. So I try to avoid it if I can.
Very nice, those are great changes.