Sending Data With Get

As mentioned in the previous chapter you can send data to the server with get almost as easily as with post but there are disadvantages. 

When you send data to the server with get the data are encoded as the query string as part of the URL. 

However from the point of view of using jQuery there is no real difference between sending data using post or get. For example to send some data to be processed by process.php you would use: 

$.get("process.php",sendData).then(
       function(data){
        alert(data)
       });

which apart from the change from post to get is identical to the earlier program.

At the server side you simply have to change the $_POST to $_GET:

<?php  echo( $_GET['first']);
 echo(filter_input(INPUT_GET,"id",
                    FILTER_VALIDATE_INT));
?>

This might well lull the beginner into a false sense of security because both the client and the server side systems are doing a lot of work to make things look this easy.

In particular jQuery does a lot of work for you and unpacks the key value pairs and URL encodes them. If you use the PHP instruction:

echo($_SERVER['REQUEST_URI']);

to send the URL back to the client for display then you will discover that it reads something like: 

/process.php?first=ian&second=elliot&
   id=27&array%5B%5D=1&array%5B%5D=2&array%5B%5D=3

The good news is that PHP automatically un-URLencodes the data for you and presents you with an array of key value pairs as in the case of post. That is post and get send data to the server it two very different ways but PHP and many other server side languages hide this difference from you as much as possible.

That is when you use get all of the data is sent using the URL as a query string.

Different browsers limit the length of a URL in different ways but traditionally a limit of around 2000 characters has been suggested. However why risk things not working when you can use a post instead. 

If you want to manually URL encode some data use JavaScript's urlencode function or jQuery's param() function. The urlencode function will only code up a string and it is up to you to construct the full query string. The jQuery param() function will accept an array, object or jQuery object and do more of the work for you. 

For example:

var q= $.param(sendData));

returns

first=ian&second=elliot&id=27
  &array%5B%5D=1&array%5B%5D=2&array%5B%5D=3

If you want to URL encode a form use jQuery's serialize method.

It is also worth knowing about the serializeArray method which will convert form into an array of name, value pairs. This is often useful if you need to do a lot of processing before sending the data. 

The bottom line is that there is little reason to use a get to send a lot of complex data - you are better of with a post. 

• If you are sending data to the sever for processing use a post.
  
  
• If you are retrieving data from the server use a get.

The main use of data on get is in customizing the response. For example sending a page number to indicate which page of an article should be displayed is a reasonable use. Also keep in mind that the user can see the query string and is often tempted to try their hand at constructing their own or editing what you have provided.  

Where Is The Data? 

When you use a post request things can get a little complicated with the interpretation of what is a URL and what is a local file system path. This is fairly straightforward and as long as you understand how URLs and files system paths work there should be no problem - however having to use both at the same time can be confusing. 

The program that processes the data will be loaded using a URL but often it has to save the data that has been sent using the local file system on the server and this can be confusing. 

The path in an Ajax URL is always interpreted as starting at the web site root. That is you cannot request a file that is stored higher up in the local file system. 

As far as the Ajax URL is concerned the website root directory is its root directory.

That is in a URL: 

• An absolute path always starts at the website root. 
  
  
• A relative path starts at the folder that the page making the request is stored in. 

That is, if your website root is:

/var/www/

and the home page is:

myserver.com/index.html

then an absolute path in a get performed within the home page such as 

/mydirectory/mydata.txt

will get the same file as a relative path mydirectory/mydata.txt, i.e. the file:  

/var/www/mydirectory/mydata.txt 

Now we come to the slight complication. 

Suppose the PHP program is to save the data and it is supplied a path to a folder to save the data to. For example:

var sendData={dir:"mydirectory/", myData:"some data"};

$.post("process.php",sendData).then(
       function(data){
        console.log(data);
       });

The following PHP program can get the directory and the data and save the data as requested:

<?php
 $dir=$_POST["dir"];
 $data=$_POST["myData"];
 $result= file_put_contents($dir."myFile", $data);
 echo($result);
?>

The file myFile will be stored in the mydirectory folder in the folder that the page was served from. If we assume that the page was served from the site root then the folder, in terms of the local file system, is:

var/www/mydirectory/ 

In other words, it is the same directory that a relative URL of the form mydirectory/ would have referred to. 

Now consider how to specify an absolute path to mydirectory - perhaps because you want to store the file in the same folder no matter where the page that makes the Ajax call was served from. By analogy with a URL which always takes a path as relative to the website root you might try:

var    sendData={dir:"/mydirectory/",
                 myData:"some data"};

Now the program doesn't work unless there is a mydirectory folder in the root of the local file system that the PHP page has permissions to write to.

That is /mydirectory/ in this case is a reference to mydirectory in the root of the local file system not in the website root.

This is perfectly reasonable as the PHP instruction is a file system command and hence it works with the usual rules of the local file system - absolute paths are from the file system root and relative paths are relative to the directory that the program is run from. However the change from relative to absolute can still be confusing in going from a URL to a local file system path. 

You can make this situation worse or better depending on your point of view by writing your server side programs to append the web directory's path. That is append /var/www to every path that the Ajax call provides. This allows the URL to refer to the same file as the file system path but if the user or the client side program doesn't know this then things still go wrong. 

Ajax and Forms

Get and post were used to send data to the server and get a response long before Ajax was invented. HTML forms use either get or post to send the data that the user enters to the server. This is where it all started, but today you can opt to handle forms yourself via Ajax. 

First a quick refresher on HTML forms. 

You create a form using the form tag, which contains a set of input elements.  

For example:

<form action="process.php" method="post">
 First name:<br>
 <input type="text" name="first" value="Enter Data">
 <br>
 Last name:<br>
 <input type="text" name="last" value="Enter Data">
 <br><br>
 <input type="submit" value="Submit">
</form>

The user can now enter data, first name, last name and when they click the submit button the data is sent to the server. The request method used is set by method, which can be post or get. The data in the form are encoded as key value pairs. The key is the name of each input element and the value is its value.

How the key value pairs are encoded depends on the method  - they are coded as the query string part of the URL if is is get and within the request body for a post. The program that is loaded by the server is specified by the action attribute. 

So in this case when the user clicks the submit button the data in first and last is coded up as

first:firstname,last:lastname

and sent to process.php. 

If the method had been set to get, i.e. method="get", then the data would have been coded as part of the URL, something like:

http://host/process.php?
                 first=Enter+Data&last=Enter+Data

A PHP program to process the form data would be something like:

<?php
 $first=$_POST["first"];
 $last=$_POST["last"];
 echo($first.$last);
?>

and this just sends the first and last name back to the client as the response. 

If this sounds a lot like the get and post you have been working with as part of Ajax then you are correct. This is where the Ajax protocol for data transfer originated - Ajax just took over what forms had been doing for ages.

So what exactly is the difference?

The difference is that with a form-based data submission the file specified as the action is returned to the client as an HTML page and it replaces the page that made the request. 

If you send the form data using Ajax then the Ajax done method receives the response and can do with it what it likes. The page that makes the request is not replaced by the response. 

For example, let's suppose we want to send the same form data to the server using Ajax.

First we have to do something about the submit button because when the user clicks it the client starts the get or post without giving you a chance to customize anything. There are many ways of activating the Ajax operation and the simplest is just to use a standard button with a suitable onClick event handler. The big problem is that clients often treat the Enter key as a signal to submit the form. 

The best way of intercepting the submit button is to attach an event handler of our own. This is particularly easy using jQuery and the submit method. The only change we have to make to the form is to give the form tag an id:

<form id="myForm" action="process.php" method="post">

Now we can add a submit event handler:

$("#myForm").submit(
    function(event){
     alert("submit");
    })

When the user clicks the submit button our event handler is called but the post to the server still occurs because the event propagates to the clients built-in event handler. 

To stop the propagation we could return false or use the preventDefault method:

$("#myForm").submit(
    function(event){
     event.preventDefault();
    })

With this change the user can click the submit button or perform any action that causes the form to be submitted and the event handler will be called and the form will not be submitted. It is better to use preventDefault because it only stops the default event handler being called. Returning false stops the event completely.