instead of doing all your server operations via the POST method token ( and the content type set to json ).
I've done some research here and I am referring to the method tokens mentioned in the ietf document.
http://tools.ietf.org/html/rfc2616#section-5.1.1
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
I don't see the benefit of using all the other server type requests. I know they are used, particularly what spurned this interest was Backbone's use as seen here:
var methodMap = {
'create': 'POST',
'update': 'PUT',
'patch': 'PATCH',
'delete': 'DELETE',
'read': 'GET'
};
These properties are eventually passed to the xhr open method which you can read about in the links I posted above.
Actually the MDN article has pretty much no information while the W3 articles seems a bit esoteric.
What you've described is an application design philosophy called Representational State Transfer (REST). The philosophy is much more encompassing than just using multiple request methods. It also covers the idea that each type of data needs its own URL, how that URL should be logically structured and what should belong to query parameters and what should be a URL path. REST is one of the earliest ideas related to Semantic Web - the idea that websites should be easily readable to machines as it is to humans (or to put it another way, the idea that the website should be easily understandable to developers as it is to regular users).
You can read the original paper describing REST here: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
REST is actually just one chapter in the whole paper. The paper describes what a web architecture should ideally look like.
The short answer is of course no. Technically speaking you're allowed to do whatever you want that works. Indeed, back when ideas of REST was first introduced there were no easy way to do PUT and DELETE requests on some browsers. So people stuck to GET and POST and the HTTP spec was updated specifically to make GET and POST have RESTful meaning.
The HTTP specification recommends that GET only be used for indempotent operations (requests with no side effect) while POST should be used whenever a request causes something to change in the server. But developers have been using GET to update databases due to easy debugging because you can just construct the query in the URL entry field in your browser. The RESTful way is to only allow POST requests to update the database (or save anything to file).
The advantage is to essentially allow developers to treat the web as an API. Allowing machines to read webpages allows for things like mashups, creating mobile apps as front-ends etc.
A good API or library is consistent. A consistent API is easier to use, easier to remember and doesn't require the developer to look-up documentation too often. REST attempts to provide this consistency by giving real meaning to the types of request. Therefore if you see PUT request you don't have to guess what it's doing.
As such, as a programmer, it is to your advantage to not only be RESTful as much as possible but also convince as many other programmers as possible to create RESTful websites. If all websites are RESTful, writing scripts to do smart things with online data becomes much easier.
On the other hand, as a programmer, you also have the freedom to disagree with other people's ideas.