RESTful API creates a globally unique resource

In our system we have accounts which contain items. An item is always associated with a singl开发者_StackOverflowe account but also has a globally unique id in the system. Sometimes it is desirable to work with an item when only its id is known.

Is it incorrect to allow access to a subordinate resource (the item) from outside it's owner (the account)? In other words, is it wrong to have 2 URI's to the same resource? This is a little tricky to explain so here is an example:

POST /inventory/accountId
  #Request Body contains new item 
  #Response body contains new item's id

GET|PUT|DELETE /inventory/accountId/guid  #obviously works and makes sense

GET|PUT|DELETE /inventory/guid  #does this make sense?

Perhaps I should rethink my resource layout and not use accounts to create items but instead take the account as a query string parameter or field on the item?

POST /inventory
  # Request body contains item w/ account name set on it

GET|POST|DELETE /inventory/uuid  #makes sense

GET|POST|DELETE /inventory/accountId/uuid #not allowed

---

I think having two URIs point to the same item is asking for trouble. In my experience, these sorts of things lead to craziness as you scale out (caching, multiple nodes in a cluster going out of sync and so on). As long as the item's ID is indeed globally unique, there's no reason no to simply refer to it as /inventory/uid

---

POST /inventory/accountId
GET|PUT|DELETE /inventory/accountId/guid  #obviously works and makes sense
GET|PUT|DELETE /inventory/guid  #does this make sense?

It makes the most sense when /inventory/guid redirects to /inventory/accountId/guid (or, I'd argue, vice-versa). Having a single canonical entity, with multiple URI's redirecting to it, allows your caching scheme to remain the most straightforward. If the two URI's instead return the same data, then a user is inevitably going to PUT a new representation to one and then be confused when it GETs an old copy from the other because the cache was only invalidated for the former. A similar problem can occur for subsequent GETs on the two. Redirects keep that a lot cleaner (not perfectly synchronous, but cleaner).

Whether to make items subordinate to accounts depends on whether items can exist without an account. If the data of an item is a subset of the data of an account, then go ahead and make it subordinate. If you find that an account is just one kind of container, or that some items exist without any container, then promote them to the top level.

---

In other words, is it wrong to have 2 URI's to the same resource?

No. It is not wrong to have multiple URI's identifying the same resource. I don't see anything wrong with your first approach as well. Remember URI's are unique identifiers and should be opaque to clients. If they are uniquely identifying a resource then you don't have to worry too much about making your URLs look pretty. I am not saying resource modeling is not important but IMO we shouldn't spend too much time on it. If your business needs that you have guid directly under inventory and also under individual accounts, so be it.

---

Are you concerned about this because of a potential security hole in letting data be available to unauthorized users? Or is your concern purely design driven?

If security is not your concern, I agree that it is perfectly fine to have 2 URIS pointing to the same resource.