After the release of MVC 2, i have started to check and play with the new features. But i couldnt understand that why do i need to use PUT or DELETE verbs ?
I have searched about it and read some articles but i couldnt get it.
What is the main purpose of DELETE and PUT (and do they have any advantages rather than using a GET or POST method) even though i can handle all of the requests with GET and POST...
The original purpose was to edit webpages using those verbs (more on the RESTful system). They have since been deprecated by the WebDAV extension. In practice, PUT and DELETE are never used (or very rarely by custom built applications).
In a RESTful architecture, DELETE is supposed to be used for requests that will remove data, and PUT is supposed to be used for requests that will insert data.
GET: Only function is to send information back to the client. It should be a repeatable operation without side effects.
POST: It does operations with side effects. It is not repeatable (if you POST twice, the server acts twice). After operation it should redirect to another page to show the results using GET.
DELETE: It's only function is to do a destructive operation, not repeatable (once the object is deleted, there is nothing else to delete).
UPDATE: It's function is to modify a single object and update it with the values sent in a POST (like) way. Repeatable.
You can fake DELETE and UPDATE with POST (as some web browsers don't recognize DELETE and UPDATE).
Please, use GET only to display information, not for operations with side effects.
Basically it's used to better distinguish actions/privileges.
Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request. Methods GET, HEAD, OPTIONS and TRACE, being prescribed as safe, should also be idempotent, as HTTP is a stateless protocol. By contrast, the POST method is not necessarily idempotent, and therefore sending an identical POST request multiple times may further affect state or cause further side effects (such as financial transactions). In some cases this may be desirable, but in other cases this could be due to an accident, such as when a user does not realize that their action will result in sending another request, or they did not receive adequate feedback that their first request was successful. While web browsers may show alert dialog boxes to warn users in some cases where reloading a page may re-submit a POST request, it is generally up to the web application to handle cases where a POST request should not be submitted more than once. Note that whether a method is idempotent is not enforced by the protocol or web server. It is perfectly possible to write a web application in which (for example) a database insert or other non-idempotent action is triggered by a GET or other request. Ignoring this recommendation, however, may result in undesirable consequences if a user agent assumes that repeating the same request is safe when it isn't.
via wikipedia
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods
First, you should check out BlaM's very good answer to this (dupe?) question.
Obviously you can technically create/update/delete resources without using REST principles, ut you're missing a point. If you still don't really get the concepts behind REST, Ryan Tomayko's blog entry is a nice place to start.