Several of my ajax applications in the past have used GET request but now I'm starting to use POST request instead. POST requests seem to be slightly more secure and definitely more url friendly/pretty. Thus, i'm wondering if there is any reason why I should use GET request at all.
I generally set up the question as thus: Does anything important change after the request? (Logging and the like notwithstanding). If it does, it should be a POST request, if it doesn't, it should be a GET request.
I'm glad that you call POST requests "slightly" more secure, because that's pretty much what they are; it's trivial to fake a POST request by a user to a page. Making it a POST request, however, prevents web accelerators or reloads from re-triggering the action accidentally.
As AJAX, there is one more consideration: if you are returning JSON with callback support, be very careful not to put any sensitive data that you don't want other websites to be able to see in there. Wikipedia had a vulnerability along these lines where the user anti-CSRF token was revealed via their JSON API.
All good points, however, in answer to the question, GET requests are more useful in certain scenarios over POST requests:
- They can be bookmarked
- They can be cached
- They're faster
- They have known consequences (assuming they don't change data), so visiting them multiple times is not a problem.
For the sake of posterity, updating this comment with the blog notes re: point #3 here, all credit to Omar AL Zabir (the author of the referenced blog post):
"Atlas by default makes HTTP POST for all AJAX calls. Http POST is more expensive than Http GET. It transmits more bytes over the wire, thus taking precious network time and it also makes ASP.NET do extra processing on the server end. So, you should use Http Get as much as possible. However, Http Get does not allow you to pass objects as parameters. You can pass numeric, string and date only. When you make a Http Get call, Atlas builds an encoded url and makes a hit to that url. So, you must not pass too much content which makes the url become larger than 2048 chars. As far as I know, that’s what is the max length of any url.
Another evil thing about http post is, it’s actually 2 calls. First browser sends the http post headers and server replies with “HTTP 100 Continue”. When browser receives this, it sends the actual body."
You should use GET where you're doing a request which has no side effects, e.g. just fetching some info. This request can:
- Be repeated without any problem - if the browser detects an error it can silently retry
- Have its result cached by the browser
- Be cached by a proxy
These things are all good. Anything which is only retrieving data (particularly public data) should really be a GET. The server should send sensible Last-Modified: and Expires: headers to allow caching if required.
There is one other difference not mentioned by anyone.
GET requests are passed in the URL string and are therefore subject to a length limit usually dependent on the browser. It seems that most are around 2000 chars.
POST requests can be much much larger - in fact not limited really. So if you're needing to request data from a web server and you're passing in lots of parameter information then a POST request might be the only option.
So, as mentioned before really a GET request is for requesting data (no side effects) while a POST request is generally used for transmitting data back to the server to be stored (with side effects). e.g. Use POST to upload a file. GET to retrieve a file.
There was a time when IE I believe had a very short GET URL string. Some applications like Lotus notes use large numbers of random characters to represent document id's. I had the displeasure of using another product that generated random strings so the page URL was unique each time. The random string was HUGE... and it didn't always work with IE6 from memory.
This might help you to decide where to use GET and where to use POST:
POST requests are just as insecure as GETs. The main difference is that POST is used to modify the state of the server application, while GET only requests data from it.
The difference matters when you use clean, "restful" URLs, where the URL itself specifies the resource, and the different methods trigger different actions on the server side.
Perhaps most importantly, GET is book-markable / viewable in url history, and searchable with Google.
POST is important where you don't want the event to be bookmarkable or able to be typed in as a URL - otherwise you (or Google crawling your URLS) could end up accidentally doing things like deleting users from your system, for example.
GET | POST |
---|---|
In GET method, values are visible in the URL | In POST method, values are not visible in the URL. |
GET has a limitation on the length of the values, generally 255 characters. | POST has no limitation on the length of the values since they are submitted via the body of HTTP. |
GET performs are better compared to POST because of the simple nature of appending the values in the URL. | It has lower performance as compared to GET method because of time spent in including POST values in the HTTP body |
This method supports only string data types. | This method supports different data types, such as string, numeric, binary, etc. |
GET results can be bookmarked. | POST results cannot be bookmarked. |
GET request is often cacheable. | The POST request is hardly cacheable. |
GET Parameters remain in web browser history. | Parameters are not saved in web browser history. |
Source and more in depth analysis: https://www.guru99.com/difference-get-post-http.html
© 2022 - 2025 — McMap. All rights reserved.
What are the advantages of using a GET request over a POST request?
" "Thus, i'm wondering if there is any reason why I should use GET request at all.
" – Prosody