• Post Reply Bookmark Topic Watch Topic
  • New Topic

Using REST for online purchases  RSS feed

 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the common problems facing online purchase applications is where an accidental extra click submits an extra purchase. In traditional web apps this is solved in a variety of ways, usually involving sessions or other transaction state. I'm wondering what a recommended REST approach to this problem might be.

As I see it the action of submitting details of a new purchase has aspects of both PUT and POST. It's like a PUT because we want any duplicate requests to be recognized and treated as the same original request. It's like a POST because fundamentally it's adding a new purchase record to the destination system.

In an ideal world it would seem that the initial purchase request would be a POST, and any duplicates/updates would be a PUT. unfortunately, though, the point of this problem is that the extra purchase request is accidental, so without some extra logic it would be sent as another POST, and result in an extra unwanted purchase.

Anyone got a RESTful solution to this conundrum?
 
Leonard Richardson
author
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My lame design for a Java-style pet shop service (done for another thread in this forum) has one solution.

http://www.crummy.com/writing/RESTful-Web-Services/PetStore/

An order is a resource created through POST but initially empty. Subsequent requests add items to the order through POST. To commit the order you change its state with PUT so that it's finalized. Depending on the design, you might be able to DELETE or un-finalize the order so long as your credit card hasn't been charged.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!