Question: 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.

```
/{fine-grained-id}/businessProcess

```

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

Answer: 
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.
> 
> /{fine-grained-id}/businessProcess
> 
> 
> 

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.