Question

Looking around, I can't name a single web application (not web service) that uses anything besides GET and POST requests. Is there a specific reason for this? Do some browsers (or servers) not support any other types of requests? Or is this only for historical reasons? I'd like to make use of PUT and DELETE requests to make my life a little easier on the server-side, but I'm reluctant to because no one else does.

Was it helpful?

Solution

Actually a fair amount of people use PUT and DELETE, mostly for non-browser APIs. Some examples are the Atom Publishing Protocol and the Google Data APIs:

Beyond that, you don't see PUT/DELETE in common usage because most browsers don't support PUT and DELETE through Forms. HTML5 seems to be fixing this:

The way it works for browser applications is: people design RESTful applications with PUT and DELETE in mind, then "tunnel" those requests through POSTs from the browser. For example, see this SO question on how Ruby on Rails accomplishes this using hidden fields:

So, you wouldn't be on your own designing your application with the larger set of HTTP verbs in mind.

EDIT: By the way, if you're curious about why PUT/DELETE are missing from browser based form posts, it turns out there's no real good technical reason. Reading around this thread on the rest-discuss mailing list, especially Roy Fielding's comments, is interesting for some context:

EDIT: There are some comments on whether AJAX libraries support all the methods. It does come down to the actual browser implementation of XMLHttpRequest. I thought someone might find this link handy, which tests your browser to see how compliant the HttpRequest object is with various HTTP options.

Unfortunately, I don't know of a reference which collects these results.

OTHER TIPS

Quite simply, the HTML 4.01 form element only allows the values "POST" and "GET" in its method attribute

Some proxy servers with tough security policies might drop them. I'm using PUT and DELETE anyways.

I've read that some browsers do not support other HTTP methods properly, though I can't name any specifics.

Rails, in particular, will pack your forms with a method parameter to explicitly set this even if the browser doesn't support those methods. That seems like a reasonable precaution if you're going to do this.

I say use all the features of HTTP, browsers be damned, lol. Maybe it'll inspire more complete and proper use of the HTTP protocol moving forward. There's more happening on the net than just POSTs and GETs. About time browser implementations reflected this.

This depends on your browser and Ajax library. For example jQuery supports all HTTP methods even though the browser may not. See for example the jQuery "ajax" documentation on the "type" attribute.

The Restlet Java framework lets you tunnel PUT and DELETE requests through HTML POST operations. To do this, you just add method=put or method=delete to your URI's query string, eg:

http://www.example.com/user=xyz?method=delete ...

This is the same as Ruby on Rails' approach (as described by @ars above).

Personally, I really don't see any purpose for using PUT or DELETE in a web application. All operations that an application performs are read or write, aka input output. Why do you need to distinguish the nature of the operation in the header of the HTTP request? I could make ajax calls with the same url of form /object/object_id and do multiple operations like delete, update, get the value, or create. Just by looking at the URL, I have no clue which one it is. By using GET and POST only, my urls will be:

/object/id/delete

/object/id/create

/object/id/update

/object/id --> implied GET

etc.

Based on my limited experience, this is a lot cleaner than hidden header request types in many cases. I am not saying one should never use PUT or DELETE, just saying, use them only if absolutely needed.

Refer to "RESTful Web API" by Leonard Richardson to read more about different use cases and conventions regarding HTTP request methods in a RESTful web api.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top