I do know for getting information from sever we use GET and for posting information we use POST. Now I have a search box where users can search for queries, But I'm using POST method for my search, say: user typed avatar 4 release date, and what I do is to take text box value, send it to server using ajax with type='post' and respond the result. As I suppose I should be using GET because i'm requesting information and am not posting.
So I was wondering is it okay to use post in my condition? Would I get any performance issue or anything else?
Just have a look here:
http://www.w3schools.com/tags/ref_httpmethods.asp
Some other notes on GET requests:
GET requests can be cached
GET requests remain in the browser history
GET requests can be bookmarked
GET requests should never be used when dealing with sensitive data
GET requests have length restrictions
GET requests should be used only to retrieve data
and POST:
Some other notes on POST requests:
POST requests are never cached
POST requests do not remain in the browser history
POST requests cannot be bookmarked
POST requests have no restrictions on data length
ys you can do with POST
ajax code
$.ajax({
url: "search_file.php",
type:"POST",
data : {serach_text:$('#text_input').val()},
dataType: "JSON",
success: function(result){
}});
'#text_input' is the id of search input
in php code you can access search_text with $_POST['serach_text']
Related
I'm trying to cache results from several pages that do heavy database processing. These pages feeds a jqGrid (it's a really nice grid component) through a JSON response. After reading several S.O. posts about jqGrid it came to my attention that jqGrid always send a random number (nd) even if you don't send anything to your server. This is to prevent an automatic cache from IE browsers (8 or less).
But since i want to cache my results on client side, i removed this nd number through prmNames: {nd: null}. It worked fine if get my results from server with a POST request, but when i try to change the verb request to GET, the nd number appears with a different name, a single underscore _.
Below theres a firebug print i took to make things clearer.
So, is this a bug or can i remove it from my requests in order to cache properly the server results?
The _ will be not sent by jqGrid by default. I suppose that you include cache: false of jQuery.ajax. Probably you used ajaxGridOptions: {cache: false} option.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
When do you use POST and when do you use GET?
If I use jQuery ajax call to communicate with server, in general, when should I use type get to call and when should I use post to call ?
POSSIBLE DUPLICATE: When do you use POST and when do you use GET?
GET:
GET is cacheable
GET can remain in browser history, and be bookmarked
If you want to be able to visit the content based on a URL (good for sharing links).
If the parameters return view-oriented content.
Some people say GET can be less safe than POST -- but to the seasoned user, this doesn't make any significant difference because they can intercept and modify headers of the request.
GET can be quicker compared to POST, as it is a one step request (POST sends headers first, then the body of the request).
POST:
Sending login data.
Sending non-ascii data.
If the data makes the URL for GET too long (over the maximum limit of characters).
If you want to make some data hidden to the typical user.
Ref:
http://www.cs.tut.fi/~jkorpela/forms/methods.html
http://thinkvitamin.com/code/the-definitive-guide-to-get-vs-post/
You need to know their differences, to know which to use. When the GET request is used, the sent data is shown in the address bar, with the url. The POST request is used to send data to the server without showing it anyway. And also POST is used to send files or other large data.
So if you're sending confident info like password, you use POST. When you're passing a data to be used in the page like "page=about" or "article_id=2", use GET.
instead of using get i usually just use $.load and fetch code chunks and insert them into the dom. i use post for pretty much everything else, or getJSON.
I feel ackward asking these fundamental questions given that I am not exactly new to web development. But I want to double-check my assumptions nevertheless...
I'm building the recording of unique image views in my application. When a user (not a bot) visits an image page, an Ajax call is made to a back-end process that collects the session info, compares for duplications and stores the visit. I have all my javascript references as well as this call at the bottom of the HTML, just before the </body> element:
$.get(basepath + "image/1329/record/human", function(data){
console.log("Data Loaded: " + data);
});
By default, the call to $.get is made asynchronous. Yet I want to test the following assumptions:
Is it correct that this method ensures that the call to the view recording script is non-blocking for the rest of the UI?
Is it correct that the back-end script will finish once called, regardless of whether the user navigates to another page?
According to jQuery .get reference...
This [$.get()] is a shorthand Ajax function, which is equivalent to:
$.ajax({ url: url, data: data,
success: success, dataType: dataType
});
And $.ajax is asynchronous (i.e. non-blocking) by default, that's what the A in Ajax means.
Also, back-end server code is started in the moment the server receives the request and then runs independently of the client staying on the page or not, unless you implement some kind of mechanism to stop the running service which I suppose you did not.
God bless!
The jQuery.get request you're making is asynchronous and will not block the DOM or other JavaScript from continuing. The get function is a shorthand method which uses jQuery.ajax.
The second question I don't have a solid answer for -- I expect it may depend more on how the back-end code is structured and whether it's told that the session/request has terminated.
API:
jQuery.get()
jQuery.ajax()
that is correct on both counts
What are the strengths of GET over POST and vice versa when creating an ajax request? How do I know which I should use at any given time? Is it a security-minded decision?
Also, what is the difference in how they are actually sent?
GETs should be used for idempotent operations, that is operations that can be safely repeated more than once without changing anything. Browsers will cache GET requests (for normal and AJAX requests)
POSTs should be generally be used for non-idenpotent operations, like saving something. Although you can use them for other operations if you want.
Data for GETs is sent over the URL query string. Data for POSTs is sent separately. Some browsers have a maximum URL length (I think Internet Explorer is 2048 characters), and if the query string becomes too long you'll get an error.
You should use GET and POST requests in AJAX calls just as you would use GET and POST requests in normal calls. Basic rule of thumb:
Will the request modify anything in your Model?
YES: The request will modify (add/update/delete) data from your data store,
or in some other way change the state of the server (cause creation of
a file, for example). Use POST.
NO: The request will not affect the state of anything (database, file system,
sessions, ...) on the server, but merely retrieve information. Use GET.
POST requests are requests that you do not want to accidentally happen. GET requests are requests you are OK with happening by a user pointing a browser to via a URL.
GET requests can be repeated quite simply since their data is based in the URL itself.
You should think about AJAX requests like you think about regular form requests (and their GET and POST)
The Yahoo! Mail team found that when using XMLHttpRequest, POST is implemented in the browsers as a two-step process: sending the headers first, then sending data. So it's best to use GET, which only takes one TCP packet to send (unless you have a lot of cookies). The maximum URL length in IE is 2K, so if you send more than 2K data you might not be able to use GET.
http://developer.yahoo.com/performance/rules.html#ajax_get
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:
URIs, Addressability, and the use of HTTP GET and 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