3 ms·

PUT is almost always the wrong way to go, since it requires a complete replacement of the target resource, meaning your browser needs to know the entire structu

PUT is almost always the wrong way to go, since it requires a complete replacement of the target resource, meaning your browser needs to know the entire structure. to add new items you would POST to /carts/<cid>/items. to update an item you would PATCH to /carts/<cid>/items/<iid> with qty=3 or some other partial attribute update what I do for my carts is PATCH to /carts/<cid>/items to partial mass-update all items with items[iid][qty]=x

jessaustin 12y ago
TFA already explains why carts don't need an id: for this application there is only one cart per account, and users only ever see their own accounts. The representation I was imagining being PUT would be an integer, like "1" or "5". The /api/cart/item_number resource could allow only the PUT and DELETE verbs, and /api/cart/ would handle GET. item_number, in this case, identifies an item that is for sale (EDIT: a SKU), not an association between such an item and a cart. EDIT: Keeping an integer at /cart/sku is the only association we need. /catalog/sku holds price and other associated values. /api/cart/ holds taxes, discounts, and whatnot. EDIT: It's as if you're arguing based on some theory you've read rather than on what we're discussing.
- leeoniya 12y ago
  fair enough on the single-cart bit. however, when you do PUT, you leave it up to the client to choose the destination id (if it is not already known), this is not good. You should add items by POSTing to an item factory such as /cart/items. The cart will create the item(s) for you and that item resource will almost certainly hold additional data that was not passed in from the client (usually just SKU + qty) such as base price, calculated discounts, tax, etc. a PUT would not be appropriate as it requires the entire resource to be replaced (or created) at the destination specified by the client. the client rarely knows the entire resource (or has the permission to modify it at will), so follow-up updates should be done via PATCH /cart/items/<iid> or (mass) PATCH /cart/items http://restcookbook.com/HTTP%20Methods/put-vs-post/ http://restcookbook.com/HTTP%20Methods/put-vs-post/

jessaustin 12y ago

TFA already explains why carts don't need an id: for this application there is only one cart per account, and users only ever see their own accounts. The representation I was imagining being PUT would be an integer, like "1" or "5". The /api/cart/item_number resource could allow only the PUT and DELETE verbs, and /api/cart/ would handle GET. item_number, in this case, identifies an item that is for sale (EDIT: a SKU), not an association between such an item and a cart. EDIT: Keeping an integer at /cart/sku is the only association we need. /catalog/sku holds price and other associated values. /api/cart/ holds taxes, discounts, and whatnot. EDIT: It's as if you're arguing based on some theory you've read rather than on what we're discussing.

leeoniya 12y ago
fair enough on the single-cart bit. however, when you do PUT, you leave it up to the client to choose the destination id (if it is not already known), this is not good. You should add items by POSTing to an item factory such as /cart/items. The cart will create the item(s) for you and that item resource will almost certainly hold additional data that was not passed in from the client (usually just SKU + qty) such as base price, calculated discounts, tax, etc. a PUT would not be appropriate as it requires the entire resource to be replaced (or created) at the destination specified by the client. the client rarely knows the entire resource (or has the permission to modify it at will), so follow-up updates should be done via PATCH /cart/items/<iid> or (mass) PATCH /cart/items http://restcookbook.com/HTTP%20Methods/put-vs-post/ http://restcookbook.com/HTTP%20Methods/put-vs-post/