131

I need a URI in my REST API to retrieve the current logged in user. Usually I use GET on resource with ID, but the client doesn't know the ID of the user.

I found the following solutions:

  • By user name

    This solution uses the user name instead of the ID of the user.

    Example:

  • With own resource

    This solution has one resource for users and one additional resource for logged in user.

    Examples:

  • With symbolic link

    This solution has a symbolic link for the ID of the user.

    Example:

  • With filter

    This solution uses a filter for the user name.

    Example:

Which one is most RESTful? What are the pros and cons?

Improve this question

3 Answers 3

Reset to default
89

It's up to you. All the approaches are 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 /me, /users/me, /users/myself, /users/current and similars, you have a locator for the authenticated user and it will always identify the concept of an authenticated user, regardless of which user is authenticated.

For more flexibility, you also can support /users/{username}.

By the way, a similar situation was addressed in Is using magic (me/self) resource identifiers going against REST principles?

* If you are interested in REST, the chapter 5 of Fielding's dissertation is a must-read.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

is it good to use current with Restful when HTTP Get is the protocol to receive data? with some ISP caching and etc? isn't caching affect Get URL? is it safe? or should we always send user id ?
Please note that sending both username and a Authentication header is prone to spoofing attacks, if the developers did not carefully check any mismatch.
What if I have a resource related to the current user? Should I prepend always /users/me, like /users/me/resources/:id?
7

I think REST URIs should uniquely identify the resource, no matter it' using userId/email/ssn or username, whichever attribute uniquely identify user in your system.

So, resource can be users (plural /users) and to make it singular we have below options,

If client has userId, resource should be something like,

GET - /users/{user-id}

If client doesn't have userId, but has username, then

GET - /users/{username}

So, as long as uri uniquely identifies user, we can use above uri patterns as a REST resource.

If, client doesn't have userId, username or email or any other attribute which uniquely identifies user in your system, then, we can have resource uri something like,

GET- /users/current

OR

GET- /users/me

But, in this case, client needs to have user specific TOKEN or session enabled, so that server can find user from active session or token passed in headers. Note, we should consider this a last option.

Improve this answer

Comments

-9

All are equally RESTful. REST is not about URIs, it is about using them RESTfully.

REST is about the client navigating application state. Part of this state may be who is the current user. All URLs can be used to get this part of application state.

Improve this answer

2 Comments

REST it's all about the URIs and how objects are related to them
REST itself, as in Fieldings thesis, says nothing about the URL structure

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.