A user identifier should never be stored in a URI. This is to enforce the REST stateless constraint (no server-side application state) according to Roy Fielding, § 6.2.5 ‘REST Mismatches in URI’ of his doctoral dissertation Architectural Styles and the Design of Network-Based Software Architectures:
Although the URI design matches REST’s architectural notion of
identifiers, syntax alone is insufficient to force naming authorities
to define their own URI according to the resource model. One form of
abuse is to include information that identifies the current user
within all of the URI referenced by a hypermedia response
representation. Such embedded user-ids can be used to maintain session
state on the server, track user behavior by logging their actions, or
carry user preferences across multiple actions (e.g., Hyper-G’s
gateways (84)). However, by violating REST’s constraints, these
systems also cause shared caching to become ineffective, reduce server
scalability, and result in undesirable effects when a user shares
those references with others.
And HTTP/1.1 basic authentication abides by the REST stateless constraint, according to Roy Fielding, § 5.1.2 ‘Considerations for New Authentication Schemes’ of his RFC 7235:
HTTP authentication is presumed to be stateless: all of the
information necessary to authenticate a request MUST be provided in
the request, rather than be dependent on the server remembering prior
requests. Authentication based on, or bound to, the underlying
connection is outside the scope of this specification and inherently
flawed unless steps are taken to ensure that the connection cannot be
used by any party other than the authenticated user (see Section 2.3
Yet HTTP/1.1 allows the storage of a user identifier in the request header field
Authorization to authenticate the user agent with an origin server, according to Roy Fielding, § 2.1 ‘Challenge and Response’ of his RFC 7235:
A user agent that wishes to authenticate itself with an origin server
— usually, but not necessarily, after receiving a 401 (Unauthorized)
— can do so by including an Authorization header field with the request.
So why is storing a user identifier in a HTTP request header field considered stateless but storing it in a URI is not?
It appears to me that transmitting a user identifier, regardless of the means (URI, header field, body), identifies a user agent with the origin server and therefore allows storing server-side application state for that user agent. In other words, to me authentication is actually the means to achieve stateful communication.