POST and GET

http://prajwal-tuladhar.net.np/2009/05/31/397/there-is-a-difference-between-http-post-and-http-put/


According to the HTTP 1.1 specification:

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request — the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

http://stackoverflow.com/questions/5926898/can-one-send-a-put-or-delete-http-request-using-the-browser
http://tomayko.com/writings/rest-to-my-wife

I just read the famous article "How I explained REST to my wife" http://tomayko.com/writings/rest-to-my-wife. Needless to say, I had a suspicion before and I am now convinced that RESTful is the best way to design a web application.

A.
It is not about browsers but about version of HTML used to define the form - both HTML 4.01 a XHTML 1.0 (I'm not sure about HTML 5) supports only GET and POST as method of HTML form. If you want to use PUT and DELETE you must either use JavaScript and XMLHttpRequest directly or some JavaScript library which simplifies this (like jQuery).

http://stackoverflow.com/questions/165779/are-the-put-delete-head-etc-methods-available-in-most-web-browsers
A.

HTML forms support GET and POST. (HTML5 at one point added PUT/DELETE, but those were dropped.)
XMLHttpRequest supports every method, including CHICKEN, though some method names are matched against case-insensitively (methods are case-sensitive per HTTP) and some method names are not supported at all for security reasons (e.g. CONNECT).
Browsers are slowly converging on the rules specified by XMLHttpRequest, but as the other comment pointed out there are still some differences.

http://www.diffen.com/difference/Get_vs_Post

• Class vs Object
• self vs this in PHP
• Echo (PHP) vs Print (PHP)
• PHP vs Ruby
• JQuery vs script.aculo.us
• Calloc vs Malloc

http://www.packetizer.com/ws/rest.html

POST

POST is similar to PUT, and therefore confusing. POST also creates a resource, like PUT. The key difference is that POST is used when the server is in control of storing information, not the client. This is usually the case when posting a blog entry, for example. If the client wishes to create a new blog entry, it is the server that is responsible for storing the information in a database and assigning a unique value and/or URI to the newly posted content.
POST is also the appropriate tool to use when the operation does not result in the creation of a resource, but perhaps the invocation of some action. As an example, using a web-based form to transmit an email message would be an appropriate use of POST.
OK, that last sentence will raise a few eyebrows in the REST community. But, alas, what system exists where there are not some "things" that do something, other than store information? If one wishes to transmit an e-mail message, for example, POST is the method to use. In that case, some action is performed, but a new resource is not created as a consequence.

Safety and Idempotence

There are two other terms associated with REST that you should know, simply because they appear in all of the literate related to REST. Those are the words "safe" and "idempotent". These words do not come from Fielding's original PhD thesis on REST, but do appear in RFC 2616 and have been popularized through the book RESTful Web Services from O'Reilly.
The word "safe" means that if a given HTTP method is invoked, the resource state on the server remains unchanged. In theory, GET is always safe. No matter how many times you download this web page, the contents of it will not change due to your repeated downloads, since you cannot change the web page in that way. That sounds obvious, but if you build a RESTful web service that uses GET in such a way as to modify any state contained within a resource, then you have violated the rules.
PUT is not safe, because if you store something on the server, then you are creating a new resource or you are modifying a resource. (Of course, one might modify a resource to contain the same representation, but that is a corner case and not the general rule we apply to PUT.)
DELETE is clearly not safe.
HEAD is safe for all the same reasons that GET is safe.
So, what about POST? Some argue that POST is not safe. But, we argue that "it depends". If a POST operation is used to create a resource (e.g., a blog entry), then it is not safe. However, if POST is used to send an e-mail, then why would it not be considered safe? In the latter case, the state of the resource did not change. As such, it is safe.
The word "idempotent" means that, regardless of how many times a given method is invoked, the end result is the same. GET and HEAD are idempotent. GET and HEAD are both safe and idempotent, actually.
PUT is also idempotent. If you issue PUT 100 times, the resource state on the server is exactly the same as if you use the PUT method one time.
DELETE is also idempotent. If you delete a resource once, it is gone. One cannot delete it again and, if one tried, it would have obviously not make state changes to the resource, since there is no resource to change.
So, what about POST? As you can tell, POST is really the "problem child" for REST. It is somewhat ill-defined in the HTTP specifications and does not map perfectly to the concepts of REST. Most of the time, POST is not idempotent, as we will discuss below. However, if the server state is not changed as a consequence of issuing a POST, it is idempotent. In most cases, though, a POST is used to create or modify a resource, and often not idempotent.
Have you ever visited a web site to post an article or blog entry, or make a payment and accidentally press "submit" twice? Often, the server will accept that and perform the request two times, because POST is not idempotent. To be useful, though, one might design a means of using POST in such a way as to make it idempotent. There are a few non-standard mechanisms out there for that, the most common approach being to use POST to first create a new resource used to accept a subsequent POST method. Then, once the POST method is received for the given resource, the resource refuses to accept any additional POST requests.
This probably requires a more concrete example. Suppose you wish to post a blog entry. You might press the "post a blog entry" link, which might result in creating a resource called "http://example.org/blog/post/123" and your web browser is now showing a web form that allows you to type the contents of the blog. When you press the "submit" button, the HTTP POST is issued to the URL "http://example.org/blog/post/123" and, once that is received, and further posting attempts are rejected. If you had inadvertently clicked on the "post a blog entry" two times, two different blog posting resources might have been created (e.g., 122 and 123), but the first one (122) should be deleted automatically at some point, restoring the server state with no ill side-effects. But, since there are no standard procedures, then we cannot tell you exactly how to implement the logic. Hopefully, you get some idea.










http://programmers.stackexchange.com/questions/120716/difference-between-rest-and-crud
http://en.wikipedia.org/wiki/CRUD

Each request contains a URL, so the server knows which resource you want to access, but it can also contain a method. A method describes what to do with that resource.

But this "method" concept wasn't used very often.

Usually, people would just link to pages via the GET method, and issue any type of updates (deletions, insertions, updates) via the POST method.

And because of that you couldn't treat one resource (URL) as a true resource in itself. You had to have separate URLs for deletion, insertion or update of the same resource. For example:

http://...com/posts/create- POST request  -> Goes to posts.create() method in the server
http://...com/posts/1/show- GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1/delete - POST request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1/edit- POST request  -> Goes to posts.edit(1) method in the server

With REST, you create forms that are smarter because they use other HTTP methods aside of POST, and program your server to be able to distinguish between methods, not only URLS. So for example:

http://...com/posts - POST request  -> Goes to posts.create() method in the server
http://...com/posts/1 - GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1 - DELETE request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1 - PUT request  -> Goes to posts.edit(1) method in the server

Remember, a single URL describes a single resource. A single post is a single resource. With REST you treat resources the way they were meant to be treated. You're telling the server which resource you want to handle, and how to handle it.