The story of the non-idempotent request

Diane has a need. She’s trying desperately to purchase Head First Knitting from the Wickedly Smart online book shop which, unbeknownst to Diane, is still in beta. Diane’s low on money—she has just enough in her debit account to cover one book. She considered buying directly from Amazon or the O’Reilly.com site, but decided she wanted an autographed copy, available only from the Wickedly Smart site. A choice she would later come to regret...

  1. image with no caption
  2. image with no caption
  3. image with no caption
  4. image with no caption
  5. image with no caption
  6. image with no caption
  7. image with no caption
  8. image with no caption
  9. image with no caption
  10. image with no caption

Flex Your Mind

What went wrong with Diane’s transaction?

(And it’s not just ONE thing... there are probably several problems the developer must fix.)

  
  
  
  

What are some of the ways in which a developer could reduce the risk of this?

(Hint: they might not all be programmatic solutions.)

The HTTP 1.1 spec declares GET, HEAD, and PUT as idempotent, even though you CAN write a non-idemtotent doGet() method yourself (but shouldn’t). POST is not considered idempotent by the HTTP 1.1 spec.

image with no caption

Being idempotent is GOOD. It means you can do the same thing over and over again, with no unwanted side effects!

image with no caption
image with no caption

Get Head First Servlets and JSP, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.