REST Mistake #1: Confirming GETs

I had dinner with Bill Venners in Santa Clara last night. A lot of the action at the recently concluded Software Development 2006 conference focused on REST, so that was very much on our minds. We’ve both spent a lot of time working on server side frameworks for publishing systems, he at Artima, me here at The Cafes and its sister sites. Gradually the conversation wandered into authentication systems.

Among other topics, I described to Bill the cookieless, registration free authentication I had designed for version 1.0 of this site. I’m no longer using that system since switching to WordPress for other reasons, but I’m still quite proud of it; and I’m not sure it’s been duplicated anywhere else. However Bill immediately noticed one fatal (but correctable) flaw in my approach.

The way the system worked you had the option to register with a user name and password. If you did so you could comment with your user name and password and the comment would be immediately posted. That’s not especially unique. Many blog and BBS systems work exactly like that. What was different was that you could also post without registering and still be authenticated. If you did not supply a user name and password, then the system would e-mail you a confirmation URL. The comment would not be posted until you clicked on the URL. At that point you’d see a screen like this one, and the comment would be published:

Thank you. Your comment has been posted.

This more or less completely eliminated spam and forged comments but was really easy for users.

The problem Bill noted was that this design isn’t RESTful. In particular I was using a GET to make something happen: confirm a message. What really shocked me was that Google’s GMail and possibly other clients will prefetch such URLs, maybe even before the user ever reads the e-mail. In other words, the confirmation can be accidental. Oops. As soon as Bill pointed it out, I saw my error. Google is absolutely within its rights to prefetch such a URL. I should not be using a GET to confirm the message. That needs to be done with a POST.

As Bill reminded me, the correct solution is to have the URL in the e-mail message go to a form page like this one:

Document Title: Verify Post    COMMENT CONFIRMATION    Here is your comment as it will appear on the site:  Tomcat and the Whedonverse    Java, XML, and the Whedonverse intersected for me some years ago. See _ Buffy in Cyberspace _ from way back in Episode 8. :-) Yes, I wrote this; and you may post it here.

The user would need to take an extra step of actually clicking on the button, which would submit the form and confirm the comment via POST, not GET. This is the correct RESTful design for this system, though it is a two-click process rather than a one-click process. From a user interface perspective, I don’t like the extra click, but it is absolutely necessary for the proper functioning of the Web.

I’m not the only one to make this mistake though. Many mailing lists use something a lot like this scheme to confirm subscriptions, and they have the exact same problems. They need to be fixed. Embarassingly the rest-discuss mailing list itself has this very problem. In fact, it has both problems. To confirm a subscription you GET a URL sent in an email message and then you GET a second URL you find on that page. In other words it’s a two-click process, but both clicks use GET, and are cacheable, spiderable, and prefetchable but not side-effect free. (In fairness, this is not just rest-discuss. All mailing lists hosted on yahoogroups have this problem. Still you’d think the RESTafarians could find a REST friendly e-mail host. For instance, the listproc software IBiblio uses to host xom-interest and other mailing lists gets this absolutely right.)

There is a RESTful solution though. Instead of sending plain text containing a URL, I could send an HTML e-mail containing a form that uses POST to submit the confirmation. That would be fully RESTful, and not require more than one click. The downside is that it requires an HTML-capable e-mail client. Most of my target audience (including me) prefers plain text e-mail so this is probably worse than the two-click solution.

(Oh, and for anyone who’s keeping score, on rereading the code I wrote two years ago, I discovered that The Cafes did actually get this right the first time. I just misremembered how my system worked when I described it to Bill over dinner last night. However the issues about mailing list confirmations and one-click vs. two-clicks are still very real.)

10 Responses to “REST Mistake #1: Confirming GETs”

  1. Avery Regier Says:

    Use javascript on the page you get by the GET call from the mail message to automatically submit the form which then confirms the message. Unless JavaScript is turned off, this will be one click. If JavaScript is turned off or the browser somehow prevents it, it is two. Google’s spidering won’t run the JavaScript, so it is safe there.

  2. Elliotte Rusty Harold Says:

    That has several problems. First, from a theoretical standpoint I’m not sure that running the confirming script automatically on the client in response to a GET is any different than running a script automatically on the server.

    Second, from a user interface perspective, the user expects to be able to click on a basic link without confirming or committing to anything.

    Third, practically, I’m not at all sure that Google (and other robots) won’t run JavaScript in the future. They’re already making efforts to process the HTML more as a real browser like Firefox would in order to identify the more and less important content on the page.

  3. bloglips - douglips blog Says:

    Confirming GETs Considered Harmful?

    Now, technically it is within a client’s right to pre-fetch any URLs they desire. But in an email client that seems irresponsible, when some of those URLs might be:Click here to confirm for my spam list that your email address is valid! (Note, this is…

  4. marten.gustafson » links for 2006-03-21 Says:

    […] REST Mistake #1: Confirming GETs (tags: rest) […]

  5. BillSaysThis Says:

    Both the GET and POST versions seem to require two clicks to me. One in the email to load the confirm page and one to dismiss the page; after all, even assuming a multi-tab capable browser not many of us are likely to leave the tab open. Further, why would you have separate Verify and Go to button/links in the POST version rather than Confirm (and Not Me) buttons which load the next page/close the tab after submission?

  6. Test Says:

    Hi all!


  7. toscana Says:

    E grande io ha trovato il vostro luogo! Le info importanti ottenute! ))

  8. börsenspiel Says:

    technically it is within a client’s right to pre-fetch any URLs they desire. But in an email client that seems irresponsible, when some of those URLs might be:Click here to confirm for my spam list that your email address is valid!

  9. spyware removal software Says:

    spyware removal software

    Features of spyware removal software.

  10. SunnyDays Says:

    First time posting here.
    Can anyone tell me their opinion of the forum thus far.
    Leave me a post and introduce yourself
    See ya,

    virgo zodiac
    web hosting