Is it legal to have REST resource such as /currentUser in terms of RESTful and stateless?

Question

In terms of RESTful and stateless it's pretty legal to have resource like

/users/123

But, the question is: is it legal to have resource that omits user id and assumes that it's implicitly resolved on the server from the user session? For example:

/loggedUser

That resource would point to /users/123 when user with identifier 123 is authorized.

Answer 1

Picking a resource locator

Using /me, /users/me, /users/myself, /users/current or similar URIs to identify a resource that corresponds to the authenticated user is perfectly fine from a REST perspective. According to Roy Thomas Fielding's dissertation, any information that can be named can be a resource:

5.2.1.1 Resources and Resource Identifiers

The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time. [...]

When using the URIs mentioned above, you have an identifier for the authenticated user and it will always identify the concept of an authenticated user, regardless of which user is authenticated.

The stateless constraint

The stateless constraint is not related to how your resources are identified. The stateless constraint is about not storing any session state on server side. In this approach, each request from client to server must contain all the necessary information to be understood by the server.

See que following quote from Fielding's dissertation:

5.1.3 Stateless

[...] each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. [...]

When targeting protected resources that require authentication, for example, every request must contain all necessary data to be properly authenticated/authorized.

---

A similar question has been answered here and here.