|Looking for ideas on a shopping cart api||Gary Davis||9/25/12 6:51 AM|
I would like to expose my shopping cart to other clients to use. I'd like them to be able to create a cart, add items to the cart (delete, update, etc), set the addresses, shipping options and ultimately submit the cart for fulfillment.
BTW, I am using ASP.Net MVC4 WebAPI. Cart IDs and Item IDs are GUIDs. SSL and an ApiKey would be required.
So I am looking for the best way to design the API Urls. I did not find any "best practice" ideas on the internet but there is a good Apigee PDF on Web Apis that will help. That PDF actually pointed me to this group.
So for starting, this is what I am looking at - any critiques are appreciated...
What about things like requesting the list of shipping options based on the cart, its items and shipping destination? What about submitting the cart? Do I use a verb or querystring argument specifying what function is needed?
For now, I am assuming the order has been paid for so don't have to be concerned about payment methods, credit cards, etc.
|Re: [api-craft] Looking for ideas on a shopping cart api||Luke Stokes||9/25/12 8:09 AM|
Hey Gary, welcome to the group!
You and I are on similar paths, it seems (I develop FoxyCart). I'm relatively new to this stuff and the REST API I've been working on isn't in production yet, but I may be able to offer some ideas.
On Tue, Sep 25, 2012 at 8:51 AM, Gary Davis <gard...@gmail.com> wrote:
This concerns me because you're creating something on the server, correct? A GET shouldn't be doing that. (see http://en.wikipedia.org/wiki/Idempotence and http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)
The get part is fine, but the creating part has the same concerns as above.
Why not just POST to /api/cart ? Also, do you need the /api/ in the path? Not that it matters, really... one key thing about REST and Hypermedia is that your client shouldn't be coding to the URI anyway. Those should be discovered via the hypmermedia links on the home page.
Seems reasonable, I guess. But the guid has more to do with a line item in the cart, right? Are you modeling line items as a resource?
What do you send as the payload of this POST?
One thing I learned about PUT is that it has to be the entire document. So I think this is correct.
I would suggest modeling those as resources such as /api/items/[upc] and such. Then your /api/cart/[guid] could have a hypermedia link to /api/cart/[guid]/items (maybe a collection rel value) which returns a collection of items in the cart. Each one of those items has a rel of self to work with that item directly (such as /api/items/[upc])
The pattern we're thinking of using is POSTing to the cart to transform it into a new resource (a Transaction, in our case). At that point, the cart item is no longer there. We get a 201 and a location header to the new transaction resource. I'm not a fan of verbs in the querystring because I think the HTTP methods give you everything you need when you think in terms or representations and transforming from one state to another.
I hope that's helpful. As we get further along with our API, I'd love for you to take a look. We actually just posted yesterday with some thoughts we're currently working through: http://www.foxycart.com/blog/the-hypermedia-debate#.UGHEUI1lQf7
|Re: [api-craft] Looking for ideas on a shopping cart api||umbrae||9/25/12 8:45 AM|
This is good feedback. In addition I'd say that as a general rule the collection resource should be pluralized, like /api/carts. This makes it more clear that this resource houses many carts, not just one.
|Re: Looking for ideas on a shopping cart api||Gary Davis||9/25/12 8:57 AM|
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
Then, to submit a cart as an order for fulfillment and other functions:
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.
|Re: [api-craft] Looking for ideas on a shopping cart api||mikeschinkel||9/25/12 2:33 PM|
On Sep 25, 2012, at 11:45 AM, umbrae <umb...@gmail.com> wrote:
> ...as a general rule the collection resource should be pluralized, like /api/carts. This makes it more clear that this resource houses many carts, not just one.