Designing URI for current logged in user in REST applications

by

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.

More Related Contents:

  1. Place API key in Headers or URL
  2. What exactly is RESTful programming?
  3. HTTP GET with request body
  4. 400 BAD request HTTP error code meaning?
  5. SOAP vs REST (differences)
  6. HTTP POST with URL query parameters — good idea or not?
  7. URL matrix parameters vs. query parameters
  8. What is the proper REST response code for a valid request but an empty data?
  9. HTTP response code for POST when resource already exists
  10. What is RESTful programming?
  11. Update an entire resource collection in a REST way
  12. When is it appropriate to respond with a HTTP 412 error?
  13. How to do a PUT request with cURL?
  14. Call a Server-side Method on a Resource in a RESTful Way
  15. What REST PUT/POST/DELETE calls should return by a convention?
  16. RESTful – What should a DELETE response body contain
  17. Response status code for searches in REST APIs
  18. Hyphen, underscore, or camelCase as word delimiter in URIs?
  19. Status code when deleting a resource using HTTP DELETE for the second time
  20. REST API DESIGN – Getting a resource through REST with different parameters but same url pattern
  21. What is the maximum length of a URL in different browsers?
  22. If REST applications are supposed to be stateless, how do you manage sessions?
  23. Transactions in REST?
  24. What is the difference between URI, URL and URN? [duplicate]
  25. Why the slow WADL uptake? [closed]
  26. @PathVariable in SpringBoot with slashes in URL
  27. How to format Swagger 2.0 text descriptions?
  28. How should the header X-DocuSign-Authentication be used for REST and SOAP?
  29. How one could use server side sorting and paging with Azure Mobile Services
  30. ‘Best’ practice for restful POST response

Leave a Comment