Article:		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/

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.
  
  Kit

• 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:
  
  http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm