When do you use POST and when do you use GET?

Question

From what I can gather, there are three categories - never use GET and use POST, never use POST and use GET, and it doesn't matter which one you use.

Am I correct in assuming those three cases? If so, what are some examples from each case?

Answer 1

Use GET when you want the URL to reflect the state of the page. This is useful for viewing dynamically generated pages, such as those seen here. A POST should be used in a form to submit data, like when I click the "Post Your Answer" button. It also produces a cleaner URL since it doesn't generate a parameter string after the path.

Answer 2

Use GET if you don't mind the request being repeated (That is it doesn't change state).

Use POST if the operation does change the system's state.

Answer 3

The original intent was that GET was used for getting data back and POST was to be anything. The rule of thumb that I use is that if I'm sending anything back to the server, I use POST. If I'm just calling an URL to get back data, I use GET.

Answer 4

My general rule of thumb is to use Get when you are making requests to the server that aren't going to alter state. Posts are reserved for requests to the server that alter state.

Answer 5

i use post when i dont want people to see the querystring or when the querystring gets large. also, post is needed for file uploads.

i dont see a problem using get though, i use it for simple things where it makes sense to keep things on the query string.

using get will allow linking to a particular page possible too where post would not work.

Answer 6

Use POST for destructive actions such as creation (I'm aware of the irony), editing, and deletion, because you can't hit a POST action in the address bar of your browser. Use GET when it's safe to allow a person to call an action. So a URL like:

http://myblog.org/admin/posts/delete/357

Should bring you to a confirmation page, rather than simply deleting the item. It's far easier to avoid accidents this way.

POST is also more secure than GET, because you aren't sticking information into a URL. And so using GET as the method for an HTML form that collects a password or other sensitive information is not the best idea.

One final note: POST can transmit a larger amount of information than GET. I don't remember the exact constraints of each, but the advantage is significant.

Answer 7

i dont see a problem using get though, i use it for simple things where it makes sense to keep things on the query string.

Using it to update state - like a GET of delete.php?id=5 to delete a page - is very risky. People found that out when Google's web accelerator started prefetching URLs on pages - it hit all the 'delete' links and wiped out peoples' data. Same thing can happen with search engine spiders.

Answer 8

There is a proper place for each. Even if you don't follow RESTful principles, a lot can be gained from learning about REST and how a resource oriented approach works.

A RESTful application will use GETs for operations which are both safe and idempotent. A safe operation is an operation which does not change the data requested. An idempotent operation is one in which the result will be the same no matter how many times you request it. It stands to reason that, as GETs are used for safe operations they are automatically also idempotent. Typically a GET is used for retrieving a resource (a question and its associated answers on stack overflow for example) or collection of resources.

A RESTful app will use PUTs (I know the question was about GET and POST, but I'll return to POST in a second) for operations which are not safe but which are idempotent. Typically a PUT is used for editing a resource (editing a question or an answer on stack overflow for example).

A POST would be used for any operation which is neither safe or idempotent. Typically a POST would be used to create a new resource for example creating a NEW SO question (though in some designs a PUT would be used for this also). If you run the POST twice you would end up creating TWO new questions.

There's also a DELETE operation, but I'm guessing I can leave that there :)

In practical terms modern web browsers typically only support GET and POST reliably (you can perform all of these operations via javascript calls, but in terms of entering data in forms and pressing submit you've generally got the two options). In a RESTful application the POST will often be overriden to provide the PUT and DELETE calls also.

But, even if you are not following RESTful principles, it can be useful to think in terms of using GET for retrieving / viewing information and POST for creating / editing information.

You should never use GET for an operation which alters data. If a search engine crawls a link to your evil op, or the client bookmarks it could spell big trouble.

Answer 9

This traverses into the concept of REST and how the web was kinda intended on being used. There is an excellent podcast on Software Engineering radio that gives an in depth talk about the use of Get and Post.

Get is used to pull data from the server, where an update action shouldn't be needed. The idea being is that you should be able to use the same GET request over and over and have the same information returned. The URL has the get information in the query string, because it was meant to be able to be easily sent to other systems and people like a address on where to find something.

Post is supposed to be used (at least by the REST architecture which the web is kinda based on) for pushing information to the server/telling the server to perform an action. Examples like: Update this data, Create this record.

Answer 10

Gorgapor, mod_rewrite still often utilizes get. It just allows to translate a friendlier URL into a URL with a GET query string.

Answer 11

Because GETs are purely URLs, they can be cached by the web browser and may be better used for things like consistently generated images. (Set an Expiry time)

One example from the gravatar page: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid

GET may yeild marginally better performance, some webservers write POST contents to a temporary file before invoking the handler.

Another thing to consider is the size limit. GETs are capped by the size of the URL, 1024 bytes by the standard, though browsers may support more.

Transferring more data than that should use a POST to get better browser compatibility.

Even less than that limit is a problem, as another poster wrote, anything in the URL could end up in other parts of the brower's UI, like history.

Answer 12

Short Version

Get: Usually used for submited search requests, or any request where you want the user to be able to pull up the exact page again.

Advantages of Get:

• Urls can be bookmarked safely.
• Pages can be reloaded safely.

Disadvantages of Get:

• Variables are pased through url as name-value pairs. (Security risk)
• Limited number of variables that can be passed. (Based upon browser. IE limited: 2,048 characters.)

Post: Used for higher security requests where data may be used to alter a database, or a page that you don't want someone to bookmark.

Advantages of Post:

• Name-value pairs are not displayed in url. (Security += 1)
• Unlimited number of name-value pairs can be passed via post. Reference.

Disadvantages of Post:

• Page that used post data cannot be bookmark. (If you so desired.)

Longer Version

Directly from the Hypertext Transfer Protocol -- HTTP/1.1

9.3 GET

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.

The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.

The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial GET requests that only part of the entity be transferred, as described in section 14.35. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client.

The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in section 13.

See section 15.1.3 for security considerations when used for forms.

9.5 POST

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

  - Annotation of existing resources;

  - Posting a message to a bulletin board, newsgroup, mailing list,
    or similar group of articles;

  - Providing a block of data, such as the result of submitting a
    form, to a data-handling process;

  - Extending a database through an append operation.

The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.