Women in Technology

Hear us Roar

  The REST of the Web
Subject:   this is not REST
Date:   2005-04-28 07:57:55
From:   nferrier
using POST parameters is *explicitly* NOT RESTfull.

It should not be done, especially if you set out to write a RESTfull HTTP service.

If you need to do PUT or DELETE from a webpage you can always use XmlHttpRequest to fire your requests for you.

If you're worried about supporting some fringe operating systems then you can check out sarissa: http://sarissa.sourceforge.net/doc/

Full Threads Oldest First

Showing messages 1 through 5 of 5.

  • this is not REST
    2005-04-29 08:16:41  kitdavies [View]

    I have done a similar job to what this article describes, though in pure java.

    I took the view that it was "semi-RESTful". That is, I supported both direct calls to doPut, doDelete, etc for those clients that could provide them, as well as the "method" parameters as described here for standard browser interaction.

    The problem I had was with PUT, which requires the server to save the resource data supplied under the URI supplied. This is slightly different than just providing a POST parameter and I regarded the workaround as a bit of a necessary hack.

    I don't have a problem with describing the method used here as RESTful. It is certainly not "pure" REST, I agree, but I think you can be pragmatic about these things as well. I believe that REST concepts per se reduce much of the complexity involved in web apps and applications based on them will undoubtably benefit. This is what is being described here.

  • this is not REST
    2005-04-28 16:44:58  jrbriggs [View]

    Using XmlHttpRequest means using javascript (& if you're supporting a wide variety of browsers, also probably means browser detection, etc). I'm trying to support the lowest common denominator which means that due to various browser constraints I'm limiting what I can use -- in addition I to keep things as simple as possible

    Developing web services is a different matter. I can afford to be stricter about how the protocols are handled and let the client (for example, an XmlHttpRequest from a browser) deal with the interaction as best it can. But in this case, my intent is a simplified web app, so it's "a best-attempt", rather than "the best attempt".

    Hope that clarifies things somewhat.
    • this is not REST
      2005-04-29 05:56:13  nferrier [View]

      "keep things as simple as possible"

      simple where? you're servlet now has a facade to allow you to pretend that it is a RESTfull interface. It isn't a RESTfull interface, it is REST + some pollution.

      sarissa (which I mentioned in my first note) is cross browser support for XmlHttpRequest so you don't need browser detection. Ok, you'd still be excluding lynx|links but were you including those anyway?

      Complicating the client side a little is preferred in REST, the view being that life is complicated enough on the server already.

      And you're article is titled "the REST of the web".
      • this is not REST
        2005-04-29 20:32:32  jrbriggs [View]

        Well, we'll have to agree to disagree, if you think that using javascript with sarissa is simpler than a standard html form. I don't
        see the use of a POSTed parameter, to subvert the http method at the server side, polluting the code as much as you seem to -- at least it's not setting an action directly within a URI (as Prescod notes in his Common Rest Mistakes).

        Do you have a reference discussing why client side complication is preferred for REST applications, because I've never come across anything with that recommendation. I'd certainly be interested in reading it.
        • this is not REST
          2005-04-30 14:27:51  nferrier [View]

          Roy Fielding's paper on architecture and REST: