As you probably know, CRUD is, among other less savory things, the most common acronym for the four basic functions of persistent storage: create, retrieve, update and delete. As we discussed on January 26th, RESTful architectures apply these four basic functions in a regular way to a set of resources. If the RESTful architecture is a Web site, then the CRUD operations create, retrieve, update and delete ma As you probably know, CRUD is, among other less savory things, the most common acronym for the four basic functions of persistent storage: create, retrieve, update and delete. As we discussed on January 26th, RESTful architectures apply these four basic functions in a regular way to a set of resources. If the RESTful architecture is a Web site, then the CRUD operations create, retrieve, update and delete map to the HTTP methods GET, PUT, POST, and DELETE.What’s wrong with this picture? The HTTP 1.1 standard defines eight methods (or verbs): HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, and CONNECT. Web service clients sometimes use all eight. Web browsers, however, typically only issue GET, HEAD, POST, and sometimes PUT requests. Most browsers are not currently capable of issuing HTTP DELETE requests.Tilt! So how does Ruby on Rails 1.2 implement a RESTful interface for the delete action without getting an HTTP DELETE request? Simple: it cheats.Actually, this gets ugly. To cause a delete action, when implementing the :method => :delete option in link_to, Rails uses JavaScript to generate a dynamic form with a hidden field named _method, and sets the value of the field to delete. When a Rails application receives a form with a _method parameter, it causes the parameter value to override the real HTTP method verb.I thought I understood the benefits of RESTful architecture, but this implementation leaves something to be desired. Software Development