REST URL structure advice

问题:

I'm trying to finalise on a restful url structure for the wishlist section of a site I'm working on. It's a pretty simple model, a user can have many wishlists and each wishlist can contain many products.

Currently I have the obvious CRUD URLs to manipulate the wishlist itself :

GET account/wishlists.json
GET account/wishlists/{id}.json
POST account/wishlists.json?name=My%20Wishlist
POST account/wishlists/{id}.json?name=My%20New%20Name
DELETE account/wishlists/{id}.json

However, I don't think I know how to structure the URLs that would add/remove a product to a wishlist :(

Here are my current choices :

1) Have the product to add as part of the URL and use the HTTP verb to define my action

POST account/wishlist/{id}/product/{product_id}.json
DELETE account/wishlist/{id}/product/{product_id}.json

or

2) Have the action as part of the URL and the product id as part of the payload

POST account/wishlist/{id}/add.json?product_id={product_id}
POST account/wishlist/{id}/remove.json?product_id={product_id}

(1) is clean and, as far as I can tell it's pretty RESTful but doesn't allow things like adding multiple products easily etc.

I'm also a bit concerned about using the DELETE verb - I'm not deleting the product or the wishlist, I'm just removing one from the other.

(2) is more explicit but veers away from REST - I wouldn't be just referring to the resource in the url, I would be referring to an operation on that resource :(

Any advice on which of the above would be more correct would be very helpful! (If there's a third option that's better than mine, feel free to correct me!)

回答1:

(1) is the only valid approach for REST, using HTTP verbs for actions.

(2) encodes method names into the URI which is more like RPC and of course not RESTful.

Concerning your shortcomings about the first approach:

• The DELETE verb is fine, because your resource is the item inside in the wishlist, not the item itself.
• You can support batch requests. For instance, you might want to allow to POST a list of items to a wishlist resource resulting in mutliple adds.

PS: Prefer HTTP content negotiation (Accept and Content-Type headers) over representation formats encoded in the URI.

回答2:

I think your first option is more in line with the REST philosophy. If you want to manipulate multiple products, you could pass the ids as a list in the body, instead of using a query parameter.

As for the delete part, given that you are deleting a subresource of wishlist, I think the intention is clear (i.e. remove the connection from the wishlist to the product). If you wanted to globally remove a product, the URL should be something like

DELETE /products/{id}

回答3:

As noted by other responses, the first option is clearly the RESTful approach. The approach to deleting products from the wishlist looks fine - after all you would be doing a DELETE on product/{product_id} to remove the product itself.

For adding products, you might wish to consider a POST to account/wishlist/{id}/product/ the body of which could contain a list of product IDs.

回答4:

Here's a nice article on how to think about REST URLs