I've seen Facebook's APIs that will sometimes start with resource id. Also, if the URI is for a business process as opposed to a fine grained resource, would it be acceptable to start the endpoint with an ID, e.g.


So the ID does not represent an item in a list of business processes, but is the key resource ID needed for the process.

  • What's the meaning of the "fine-grained-id"? Do you have a link to the description of the API?
    – andih
    Commented May 27, 2017 at 3:21
  • 4
    REST has nothing to do with how you shape your API. URI are meant to be opaque and meaningless
    – Laiv
    Commented May 27, 2017 at 10:11
  • The resource ID is an ID for a resource that is a part of the business process. A series of table updates are needed to complete the process, and the ID is the key that drives the process.
    – Les
    Commented May 27, 2017 at 17:09
  • Reading again the question I come to the conclusion that It's not clear what are you asking. The short answer to the question in the title is Yes. If you were asking about the reasoning of such implentation, I'm affraid the answer is potentially opinionated
    – Laiv
    Commented May 29, 2017 at 20:21

3 Answers 3


Roy Fielding introduced REST - https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm - and I don't believe there's anything in his dissertation prescribing a particular URI scheme. As long as your scheme is consistent it should be fine. It would also be advisable if it makes some kind of sense to users why the structure exists, even if it's not a public API.

  • Basically looking to see if there is really any "best practice" for something like this. As there is no standard per se, and guidelines I've seen only revolve around the actions on a single resource and big a chain of them.
    – Les
    Commented May 27, 2017 at 17:14
  • REST and the web architecture principles are flexible enough to allow customization in its implementation. That's a key factor for architectures designed to last for a long run.
    – Laiv
    Commented May 29, 2017 at 8:49

A key tenet of RESTful interfaces is that they: identify information.

For example, if you wanted to READ information - e.g. User 123, then you should send a GET request with the id as 123.

Where the ID of the user is located, within the URL, is immaterial. Generally most routes specify the ID at the end of the URL. But you can certainly specify it where ever you like. You don't even need the http protocol to make a restful interface. so long as you can identify the resource - whether at the start of the uri or at the end - it doesn't matter.



I'm not familiar with the Facebook API, but you should avoid putting actions or processes in your URLs if the intent is to call that action by making a request to that URL. For example this is wrong

GET /infrastructure/database/reshard

Instead, the client should put the abstract database resources into the resharding state and then tell the server that is the new state of the database.

PUT /infrastructure/database

{state: resharding}

The only actions you can perform on a resource are defined in the HTTP spec (GET, POST, PUT, DELETE etc). HTTP is about state transfer. The client doesn't ask the server to perform an action on a resource it has (client: please reshard the database).

Instead, it changes the state of a resource (which is an abstract concept remember) and then uses the simple HTTP actions to let the server know it has updated this resource and the server should get in sync (client: I've put the database into this new state of resharding, update your representation of this resource)

The physical database gets physically resharded as a side-effect of the server syncing up its state of the resource with the state of the client.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.