If you think you are writing RESTful applications and your URLs look like this:

http://mydomain.com/myapp/rest/controller?method=updatePerson&fname=Jarrod&lname=Roberson&bunchmorefreeform=data

Then you are NOT doing rest, you are doing Remote Procedure Calls (RPC) over HTTP/GET. Which is about as opposite of the entire REST manifesto as you can get. I have worked on countless projects that I have joined mid-development cycle that claim to be RESTful, and they are nothing but custom RPC over HTTP/GET.

When REST documentation talks about VERBS they don’t mean parameters to a GET. They mean the METHOD that is sent as part of the HTTP call.

GET /index.html HTTP/1.1

The METHOD in the above snippet is GET. The other HTTP METHODs are POST, HEAD, OPTIONS, PUT, DELETE and TRACE. REST stands for Representational State Transfer. Remember the Representational part, it is important!

So the proper way to update a resource on the server is to do a GET, which should return the entire object in some serialized form (XML, JSON, YAML, binary blob, etc.), its Representation which is Transfered to you then you modify and do a PUT to send the Representation of the resource back to the server to be updated. Some will argue that you could POST the results back as well. I figure if you are going to drink the REST kool-aid, you should drink the entire pitcher. POST is just a way to get around having a really long GET parameter string and just another RPC style invocation. You really should do a PUT, with the new Representation of the resource you are modifying.

So either people don’t really understand the REST manifesto, or they are lazy because browsers only really support GET/POST and they don’t want to learn how to actually use the full HTTP/1.1 specification.

So what is a good REST example, for one there is WebDAV .
Having developed a carrier grade WebDAV solution, I can say that WebDAV really is the ultimate REST implementation. The addition of MKCOL, COPY, MOVE, LOCK, UNLOCK, PROPFIND, and PROPPATCH and the optional versioning features, it should be the defacto standard for RESTful services to sit on top of. Unfortunately most people read the first few paragraphs and think WebDAV is just an HTTP interface over a file system, because that is what 99% of the implementations do. This is an unfortunate disservice to what WebDAV conceptually represents. WebDAV can be implemented over an any RDBMS, Hierarchical Database, a key-value store like CouchDB, over an index like Xapian or Lucene, or a Distributed Hashtable, a Tuple Space or of course it can me mapped over a filesystem.

With the extended METHODs of the WebDAV specification, there is no need for the silly method=myspecialmethod and a bunch of free-form text parameters inventions that is a complete travesty to the basic idea behind REST. I hope this gets someone thinking about how to really do REST properly, and using WebDAV as a springboard is a great way to start!