Thanks for the useful info, Luke.
The /api on the requests is because the web server hosts other things (mostly .asmx DotNET web services).
The GET /api/cart getting a new empty cart does not really create a cart in the database, that's why I think it is not really needed. The caller can create the object and initialize the key (guid) and then use the POST.
The GET /api/cart/[guid] returning a cart if not found - it makes sense to instead return a Not Found instead.
I am not sure about the hypermedia links you mentioned. I will investigate that (your blog entry from yesterday, for example).
The [guid] is basically the cart ID and the [upc] is basically the ID of the items in the cart.
Perhaps I should have the items specified in the url as a resource as
GET /api/cart/[guid]/items/[upc]
Then, to submit a cart as an order for fulfillment and other functions:
POST /api/cart/[guid]/order
GET /api/cart/[guid]/shipoptions - Get shipping options/costs based on items/shipping destination
GET /api/cart/[guid]/order - Get order status/confirmation ID
Let's say the user selects First Class Shipping from the options. Do I update the cart with the selected option using PATCH (partial update)?
PATCH /api/cart/[guid]/shipoptions/[selectedoption] - or use JSON in content
Pluralizing to /api/carts is possible. Then GET /api/carts could provide a list of carts based on a filter to get cart(s) for a user, for example.
Thanks,
Gary