views:

302

answers:

6

Which one of these Uris would be more 'fit' for receiving POSTS (adding product(s))? Are there any best practices available or is it just personal preference?

/product/ (singular) or

/products/ (plural)

Currently we use /products/?query=blah for searching and /product/{productId}/ for GETs PUTs & DELETEs of a single product.

A: 

You POST or GET a single thing: a single PRODUCT.

Sometimes you GET with no specific product (or with query criteria). But you still say it in the singular.

You rarely work plural forms of names. If you have a collection (a Catalog of products), it's one Catalog.

S.Lott
Most recommendations I've seen for RESTful APIs say the opposite. It tends to make more sense to have /products and /products/{id} as the root is the collection (plural) and the one with an identifier is one item in that collection (selection from plural == singular). Products may be considered to be a catalog, but what if it's movies or comments?
Greg Beech
While true -- even StackOverflow uses the plural collections in their URL's -- I disagree. Singular makes more sense because a URI identifies a (singular) resource -- particularly for POST.
S.Lott
A URI does identify a resource. Sometimes a resource is a list of things. I see no reason to limit yourself to singular nouns.
Darrel Miller
Plurals aren't informative. That's why. You know the plural. Except in a few cases, it's the noun + "S".
S.Lott
+1  A: 

Since POST is an "append" operation, it might be more Englishy to POST to /products, as you'd be appending a new product to the existing list of products.

As long as you've standardized on something within your API, I think that's good enough.

Since REST APIs should be hypertext-driven, the URI is relatively inconsequential anyway. Clients should be pulling URIs from returned documents and using those in subsequent requests; typically applications and people aren't going to need to guess or visually interpret URIs, since the application will be explicitly instructing clients what resources and URIs are available.

Rob Hruska
I would go further and say that using the plural form is definitely more natural than the singular.
Darrel Miller
If you're trying to create a readable URL slug, the singular can sometimes sound more natural (to human readers), e.g. "/product/15", read straight across is "Product 15", so you know you're dealing with a single, unique product. But then you're left with what to do with the "list of all products", putting it at /product (which sounds weird for a list) or /products (having to support two URIs for the same type of resource in your code). But in any case, readable URI slugs aren't typically the goal of a RESTfully designed application, since it's not usually for human consumption.
Rob Hruska
Re-reading my comment I realized that my intent was not very clear. I prefer to use plural for using a POST to append, but a non-plural for GET and PUT if the resource is a single entity. As I've stated in the past naming REST uris is as important as naming of classes and methods in OO design. i.e. It is not essential to use good names, but it really helps.
Darrel Miller
@Rob Hruska/@Darrel Miller: Acckk! Singular URLs add complexity and cause people to think about URLs in ways that don't map to their usage. URLs should not be viewed as a sentence but instead as a hierarchy; "/products/15" is the only one that should be considered, IMO.
MikeSchinkel
@Mike I think there are far more important things to debate than the grammatical correctness of URLs. Having said that, I reserve subresources of collection resources for subsetting. E.g. /Products/Obsolete or /Products/Hot, or Products/RecentlyViewed
Darrel Miller
@Mike also from an implementation perspective I would have a ProductsController that returns a list resource and a ProductController that takes a parameter and returns a single resource. Using the same "Products" segment to map to both controllers is not as natural for me.
Darrel Miller
@Darrel Miller: Fair points. FYI I've been reading your SO contributions for a few hours now and it makes me want to write a blog post to discuss points about REST for which you are hard-line. I can learn a lot from your experience but feel that some of your opinion is driven by what it appears you value (ease of maintaining complex internal systems) and what (it appears) you don't value (ease of adoption of less complex public APIs.) Unfortunately I just don't have time to do that blog post justice today or in the near future. :(
MikeSchinkel
A: 

Typically you use POST to create a resource when you don't know the identifier of the resource in advance, and PUT when you do. So you'd POST to /products, or PUT to /products/{new-id}.

With both of these you'll return 201 Created, and with the POST additionally return a Location header containing the URL of the newly created resource (assuming it was successfully created).

Greg Beech
A: 

you could use the same url for all of them and use the MessageContext to determine what type of action the caller of the web service wanted to perform. No language was specified but in Java you can do something like this.

WebServiceContext ws_ctx;
MessageContext ctx = ws_ctx.getMessageContext();
String action = (String)ctx.get(MessageContext.HTTP_REQUEST_METHOD);
if(action.equals("GET")
  // do something
else if(action.equals("POST")
  // do something

That way you can check the type of request that was sent to the web service and perform the appropriate action based upon the request method.

ChadNC
But which URI should he use, the singular or plural?
Rob Hruska
Whichever one he wants would work. I have several rest services that perform different operations based upon the request method.He could use the plural one or the singular one since the the operation that will be carried out will only be dependent upon the request method.So /product?query=blah could could handle the same request as /products?query=blah by making use of the request method.I hope that makes sense it's been a long day and my brain is tired.
ChadNC
A: 

I would only post to the singular /product. It's just too easy to mix up the two URL-s and get confused or make mistakes.

Marcus
Aaack. Post to plural, not singular. Plural gives an index that makes sense, singular does not.
MikeSchinkel
A: 

In RESTful design, there are a few patterns around creating new resources. The pattern that you choose largely depends on who is responsible for choosing the URL for the newly created resource.

If the client is responsible for choosing the URL, then the client should PUT to the URL for the resource. In contrast, if the server is responsible for the URL for the resource then the client should POST to a "factory" resource. Typically the factory resource is the parent resource of the resource being created and is usually a collection which is pluralized.

So, in your case I would recommend using /products

Bryan Kyle