This and the following sections will briefly cover how to create basic web applications using PHP. What was discussed in the section is clearly not enough for your application to communicate with the user and formulate depending on the actions he performed or the parameters he entered. What's missing? There is not enough knowledge on how to organize user data input and transfer of this data to the server. Well, you should already have basic knowledge about how to programmatically process information received on the server.

HTTP request methods and their parameters

Any dynamic web application generates a response to the user in accordance with the parameters entered by him or the actions performed on the client side. Contacting the server most often comes down to two types of requests: using the GET method or the POST method. A few words about the differences between these two types of requests.

GET method:

The parameters are passed in the HTTP request header, so they are visible in command line, and such a request can be saved in bookmarks. Since the total length of the header is limited, the number and length of parameters passed using GET is also limited.

It is believed that the results of several identical GET requests executed in a row should be the same.

POST method:

Request parameters are passed in the body of the HTTP request, so they are not present on the command line. The number and size of parameters is unlimited.

It is believed that the results of multiple identical POST requests may return different values ​​because they may change the properties of the target object.

The GET method should be used to retrieve the contents of an information resource according to parameters when there is no need to make changes to the data structures of the target resource, and it makes sense to save the request (URL) in bookmarks. The GET method may be faster than similar requests using the POST method.

The POST method should be used when you need to hide parameters passed to the server from the URL. This method should also be used in requests for changes to the contents of the target resource, passing a description of these changes in the parameters (in the body of the request).

Path to resource?parameter1=value1¶meter2=value2&…

If you do not have a special HTML form for filling in parameters, then you can debug your PHP application by passing test parameters directly on the browser command line, for example:

Http://site/php-samples/sql.php?sql=select * from d_staff

To access request parameters on the server side, you should use global arrays $_GET And $_POST respectively. If your application doesn't care which method it is accessed by, then you should use an array $_REQUEST, which combines the data of the $_GET and $_POST arrays, for example, like this:

$sql = isset($_REQUEST["sql"]) ? $_REQUEST["sql"] : "";

In this example, the program determines whether the “sql” parameter was passed: if yes, it assigns its value to the corresponding variable, and if not, it assigns it an empty value.

Defining HTTP request parameters via HTML form

Of course, defining parameters manually directly in the browser command line is not very convenient. This method is suitable for programmatic execution of HTTP requests when web applications communicate with each other. In order to enter and carry out initial data verification on the client side, you should use HTML forms and . Below is an example simplest form, with which a text parameter (value) is entered, which is subsequently passed to the server as a parameter of the POST method.

method ="post" action =’sql.php’ > SQL:
<b>name</b> </u>="sql" cols="100" rows="8">

The method attribute of the form element specifies the method that determines the method of transmitting data to the server (get or post). The action attribute specifies php file , which will process the request. If the handler should be the current file, then the action attribute does not need to be added. For all elements whose value must be passed as an HTTP request parameter, you must define a unique value for the name attribute. It is the attribute value name will be index in the $_GET, $_POST or $_REQUEST arrays (see example above). Pressing a button submit sends the form with all entered values ​​to the server.

The first method to perform a PHP POST request is to use file_get_contents . The second method will use fread in combination with a couple of other functions. Both options use the stream_context_create function to fill in the required request header fields.

Code Explanation

The $sPD variable contains the data to be transferred. It must be in HTTP request string format, so some special characters must be encoded.

In both the file_get_contents function and the fread function we have two new parameters. The first one is use_include_path . Since we are making an HTTP request, it will be false in both examples. When set to true to read a local resource, the function will look for the file at include_path .

The second parameter is context, which is populated with the return value of stream_context_create, which takes the value of the $aHTTP array.

Using file_get_contents to make POST requests

To send a POST request using file_get_contents in PHP, you need to use stream_context_create to manually fill in the header fields and specify which “wrapper” to use - in in this case HTTP:

$sURL = "http://brugbart.com/Examples/http-post.php"; // POST URL $sPD = "name=Jacob&bench=150"; // POST data $aHTTP = array("http" => // Wrapper that will be used array("method" => "POST", // Request method // Request headers are set below "header" => "Content- type: application/x-www-form-urlencoded", "content" => $sPD)); $context = stream_context_create($aHTTP); $contents = file_get_contents($sURL, false, $context); echo $contents;

Using fread to perform POST requests

You can use the fread function to make POST requests. The following example uses stream_context_create to compose the necessary HTTP request headers:

$sURL = "http://brugbart.com/Examples/http-post.php"; // POST URL $sPD = "name=Jacob&bench=150"; // POST data $aHTTP = array("http" => // Wrapper that will be used array("method" => "POST", // Request Method // Request headers are set below "header" => "Content- type: application/x-www-form-urlencoded", "content" => $sPD)); $context = stream_context_create($aHTTP); $handle = fopen($sURL, "r", false, $context); $contents = ""; while (!feof($handle)) ( $contents .= fread($handle, 8192); ) fclose($handle); echo $contents;

Making GET Requests with PHP

We will now focus on using fread and file_get_contents to download content from the internet via HTTP and HTTPS. To use the methods described in this article, you must enable the fopen wrappers option. To do this, you need to set the allow_url_fopen parameter to On in the php.ini file.

Performing POST and GET requests in PHP is used to log into websites, retrieve web page content, or check for new versions of applications. We'll cover how to make simple HTTP requests.

Using fread to download or receive files over the Internet

Remember that web page reading is limited to the accessible portion of the packet. So you need to use the function stream_get_contents ( similar to file_get_contents) or a while loop to read the contents in smaller chunks until the end of the file is reached:

In this case of processing a PHP POST request, the last argument of the fread function is equal to the fragment size. It should generally not be greater than 8192 ( 8*1024 ).

What they have in common is that they work the same way. There is technically no difference between them. But there are ideological differences.

I'll talk about them in the context of PHP. Please note that the HTTP protocol is indirectly related to PHP because it was created for exchanging html pages and PHP simply expands the capabilities of both.

GET request is used to receive data and POST is used to send. (Remember that technically they work the same).

Therefore, in the context of PHP, based on this ideology, we did the following:
1. Every time you start PHP, superglobal arrays ($_GET, $_POST) are created by default.
2. If there is a question mark(?) in the query string. Everything after it is considered parameters GET request, they are presented in the format "key"="value" and the ampersand character (&) is used as a delimiter.
Example:
GET /index.php?name=Andrey&surname=Galkin
This is a query string, there are 2 parameters. these parameters will go into the $_GET array.
3. $_POST is filled in a different way. the contents of this array are filled from the "request headers". That is, from a place clearly hidden from view. The browser takes care of all the chores of creating such headers. Although sometimes something is edited in the headings manually.

Most often, a post request is used in forms (to send data).

For example, we have a login form with 2 fields: login and password.

Let's imagine that we are using the GET method. Then, when submitting the form, we will go to the following address /login.php?login=Andrey&password=123 You will agree that transmitting such information this way is not at all safe. Anyone can open your browser and, starting to enter the site address, they can see your passwords and logins from the history.

But if we specified the POST method, we would receive the following request:
POST /login.php (login=Andrey&password=123) what is in brackets would be hidden and not saved in any way in the browser.

To sum it up:
GET is to get a specific page in a certain form(sorting, current page blog, search bar, etc.).
POST - for sending data that does not affect the display of the page, in the sense that this data only affects the result of the script (logins, passwords, credit card numbers, messages, etc.).

And another good news is that they can be combined, for example
POST /index.php?page=login (login=Andrey&password=123) I think I have already explained enough what will come of this and which parameters will go into which array.

IN Lately I am increasingly seeing questions on the main PHPClub forum on the topic of creating POST and GET requests, as well as questions on the topic: “How can I generate a POST request using the header function.” I believe that the need to dot the “i”s in the use of this technology, since novice programmers simply do not understand the principles of the web as such. So, let's begin our journey through the world of the HTTP protocol.

1. HTTP protocol. Introduction

I would like to clarify one small thing right away.

The terrible word protocol is nothing more than an agreement of many people, just at one fine moment people decided: “Let's do it this way, and then everything will be fine.” There is nothing to be afraid of, everything is simply outrageous and we will now reveal this disgrace. So, what is the HTTP protocol and what is it used for?

There are no miracles in the world, and especially in the world of programming and the Internet!

Accept this as an unshakable truth. And, if the program does not work or does not work as desired, then, most likely, it is either written incorrectly or contains errors. So, how does the browser ask the server to send it anything?

Yes, very simple! You just need to relax a little and start enjoying the process :-)

1.2. Writing our first HTTP request

• If you think that everything is too complicated, then you are mistaken. Man is designed in such a way that he is simply not capable of creating something complex, otherwise he himself will get confused in it :-) So, there is a browser and there is a Web server.
• The browser is always the initiator of data exchange. A Web server will never simply send anything to anyone so that it sends something to the browser - the browser must ask for it.
• The simplest HTTP request might look like this:
• GET http://www.php.net/ HTTP/1.0\r\n\r\n

GET (translated from English means “get”) - a type of request; the type of request can be different, for example POST, HEAD, PUT, DELETE (we will look at some of them below). http://www.php.net/ - URI (address) from which we want to receive at least some information (naturally, we hope to learn the HTML page). HTTP/1.0 is the type and version of the protocol that we will use when communicating with the server.

\r\n is the end of the line, which must be repeated twice; why will become clear a little later.

You can perform this request very simply. Run the telnet.exe program, enter www.php.net as the host, specify port 80, and simply type this request by pressing Enter twice as \r\n\r\n. In response you will receive HTML code

home page site www.php.net.

• 1.3 Request structure Let's look at what an HTTP request consists of.

Everything is quite simple. Let's start with the fact that an HTTP request is a completely meaningful text. What does it consist of in the general case? We will consider the HTTP 1.0 protocol. So:

• Request-Line[General-Header | Request-Header | Entity-Header ]\r\n[ Entity-Body ]
• Request-Line- a relative or absolute link to a page with a set of parameters, for example, /index.html or http://www.myhost.ru/index.html or /index.html?a=1&b=qq.
• In the latter case, the server will be sent a request with a set of variables a and b with the corresponding values, and the “&” sign - an ampersand - serves as a separator between the parameters. HTTP-Version

- version of the HTTP protocol, in our case "HTTP/1.0".

We are extremely interested in GET and POST processing methods. With the GET method you can simply pass parameters to the script, and with the POST method you can emulate form submission. For the GET method, the Request-URI might look like this:

• "/index.html?param1=1¶m2=2". General-Header
  - the main part of the title.
  Format:
• Can only have two parameters: Date or Pragma. Date - Greenwich date in the format "Day of week, Day Month Year HH:MM:SS GMT", for example, "Tue, 15 Nov 1994 08:12:31 GMT" - date of creation of the request. Pragma can have a single no-cache value, which disables page caching.

  Request-Header - part of the header that describes the request..
  Request-Header can have the following parameters:

• Allow, Authorization, From, If-Modified-Since, Referer, User-Agent In this chapter, we will not consider the Authorization parameter, since it is used to access private resources, which is not needed very often.
  You can learn how to create an authorized access header yourself at www.w3c.org.
  Allow
• - sets acceptable processing methods. - Format: "Allow: GET | HEAD\n". The parameter is ignored when specifying the POST processing method in Request-Line. Specifies acceptable request processing methods.
  Proxy servers do not modify the Allow parameter and it reaches the server unchanged.
  From e-mail address who sent the request.
• Format: "From: adderss\r\n". For example, "From:
  [email protected]
  \r\n".
• If-Modified-Since- indicates that the request has not been modified since such and such a time.
  Format: "If-Modified-Since: date\r\n"
  Used only for the GET processing method. The date is specified in GMT in the same format as for the Date parameter in the General-Header.
• Referrer- an absolute link to the page from which the request was initiated, i.e. a link to the page from which the user came to ours.
  Format: "Referrer: url\n".
• Example: "Referrer: www.host.ru/index.html\n". User-Agent
  This part of the request specifies parameters that describe the body of the page. Entity-Header can contain the following parameters: Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified, extension-header.
• Allow, Authorization, From, If-Modified-Since, Referer, User-Agent- a parameter similar to Allow from General-Header.
• Content-Encoding- data encoding type Entity-Body.
  Format: "Content-Encoding: x-gzip | x-compress | other type\n".
  Example: "Content-Encoding: x-gzip\n". The "|" character means the word “or”, that is, this or that or that, etc.
  Another type may indicate how the data is encoded, for example, for the POST method: "Content-Encoding: application/x-www-form-urlencoded\n".
• Content-Length- the number of bytes sent to the Entity-Body. The Content-Length value has a completely different meaning for data sent in MIME format, where it acts as a parameter for describing a part of the data - "external/entity-body".
  Valid numbers are integers from zero and above.
• Example: "Content-Length: 26457\n". Content-Type
  - type of transmitted data.
• For example: "Content-Type: text/html\n". Expires
  - The time when the page should be removed from the browser cache.
• Format: "Expires: date\n". The date format is the same as the date format for the Date parameter from General-Header. Last-Modified
  - time of the last change of the transmitted data.
• Format: "Last-Modified: date\n". The date format is the same as the date format for the Date parameter from General-Header. extension-header
  - part of the header, which may be intended, for example, to be processed by a browser or other program that receives the document. In this part, you can describe your parameters in the format "ParameterName: parametervalue\n". These parameters will be ignored if the client program does not know how to process them.

For example: "Cookie: r=1\r\n" - sets well-known cookies for the page.

And now, after such terrible words, let's try to calm down a little and understand what we need? Naturally, we will understand with examples.

Let's imagine that we need to get a page from the site by passing Cookies, otherwise we will simply be sent as uninvited guests, and moreover, it is known that you are allowed to access this page only after you have visited the main page of the site.

2 GET method

Let's write our request.
GET http://www.site.ru/news.html HTTP/1.0\r\n

Host: www.site.ru\r\n
Cookie: income=1\r\n

This request tells us that we want to get the contents of the page at http://www.site.ru/news.html using the GET method. The Host field indicates that this page is located on the www.site.ru server, the Referer field indicates that we came for news from the main page of the site, and the Cookie field indicates that we were assigned such and such a cookie. Why are the Host, Referer and Cookie fields so important? Because normal programmers, when creating dynamic sites, check the data fields that appear in scripts (including PHP) in the form of variables. What is this for? In order, for example, to prevent the site from being robbed, i.e.

they didn’t set a program on it for automatic downloading, or so that a person visiting the site would always get to it only from the main page, etc.

Now let's imagine that we need to fill out the form fields on the page and send a request from the form, let there be two fields in this form: login and password (login and password) - and, of course, we know the login and password.
GET http://www.site.ru/news.html HTTP/1.0\r\n
GET http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
Host: www.site.ru\r\n
Cookie: income=1\r\n

Referer: http://www.site.ru/index.html\r\n Our login is "Petya Vasechkin" Why should we write Petya%20Vasechkin? This is because special characters can be recognized by the server as signs of the presence of a new parameter or the end of a request, etc. Therefore, there is an algorithm for encoding parameter names and their values ​​in order to avoid error situations in the request. Full description

of this algorithm can be found, and in PHP there are functions rawurlencode and rawurldecode for encoding and decoding, respectively. I would like to note that PHP does the decoding itself if encoded parameters were passed in the request. This concludes the first chapter of my acquaintance with the HTTP protocol. In the next chapter we will look at building requests like POST (translated from English as “send”), which will be much more interesting, because This is the type of request that is used when sending data from HTML forms.

3. POST method.

3.1 Content-Type: application/x-www-form-urlencoded.

We write a request similar to our GET request to transfer the login and password, which was discussed in the previous chapter:

GET http://www.site.ru/news.html HTTP/1.0\r\n
GET http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
Host: www.site.ru\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 35\r\n
Cookie: income=1\r\n

Here we see an example of using the Content-Type and Content-Length header fields. Content-Length tells how many bytes the data area will occupy, which is separated from the header by another line break \r\n. But the parameters that were previously placed in the Request-URI for a GET request are now in the Entity-Body. It can be seen that they are formed in exactly the same way, you just need to write them after the title. I want to point out one more thing important point

, nothing prevents, simultaneously with the set of parameters in the Entity-Body, placing parameters with other names in the Request-URI, for example:
.....
Cookie: income=1\r\n
POST http://www.site.ru/news.html?type=user HTTP/1.0\r\n

login=Petya%20Vasechkin&password=qq

3.2 Content-Type: multipart/form-data

As soon as the Internet world realized that it would be nice to send files through forms, the W3C consortium set about refining the POST request format. By that time, the MIME format (Multipurpose Internet Mail Extensions - multi-purpose protocol extensions for generating Mail messages) was already widely used, therefore, in order not to reinvent the wheel, we decided to use part of this message generation format to create POST requests in the HTTP protocol.

What are the main differences between this format and the application/x-www-form-urlencoded type?

The main difference is that Entity-Body can now be divided into sections, which are separated by boundaries (boundary). What's most interesting is that each section can have its own header to describe the data that is stored in it, i.e.

in one request you can transfer data of various types (as in a Mail letter, you can transfer files at the same time as text).
GET http://www.site.ru/news.html HTTP/1.0\r\n
GET http://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
Host: www.site.ru\r\n

So let's get started. Let's consider again the same example with the transfer of login and password, but now in a new format.
Cookie: income=1\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Content-Length: 209\r\n
--1BEF0A57BE110FD467A Content-Length: 209\r\n
Content-Length: 209\r\n
\r\n Content-Length: 209\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Content-Length: 209\r\n
Content-Disposition: form-data; name="login" Content-Length: 209\r\n
Content-Length: 209\r\n
Petya Vasechkin Content-Length: 209\r\n
Content-Disposition: form-data; name="password" Content-Length: 209\r\n

Now let's understand what is written. :-) I specially highlighted some \r\n characters in bold so that they do not merge with the data. If you look closely, you will notice the boundary field after Content-Type. This field specifies the section separator - border. A string consisting of Latin letters and numbers, as well as some other symbols (unfortunately, I don’t remember which others) can be used as a border. In the body of the request, “--” is added to the beginning of the boundary, and the request ends with a boundary, to which the characters “--” are also added to the end. Our request has two sections, the first describes the login field, and the second describes the password field.

Content-Disposition (the data type in the section) says that this will be data from the form, and the name field specifies the name of the field. This is where the section header ends and what follows is the section data area in which the field value is placed (no need to encode the value!).

I would like to draw your attention to the fact that you do not need to use Content-Length in section headers, but in the request header you should and its value is the size of the entire Entity-Body, which appears after the second \r\n following Content-Length: 209\ r\n. Those. Entity-Body is separated from the header by an additional line break (which can also be seen in sections).

Now let's write a request to transfer a file.
GET http://www.site.ru/news.html HTTP/1.0\r\n
POST http://www.site.ru/postnews.html HTTP/1.0\r\n
Host: www.site.ru\r\n
Referer: http://www.site.ru/news.html\r\n
Content-Type: multipart/form-data; boundary=1BEF0A57BE110FD467A\r\n
Cookie: income=1\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Content-Length: 209\r\n
Content-Length: 491\r\n Content-Length: 209\r\n
Content-Length: 209\r\n
Content-Disposition: form-data; name="news_header" Content-Length: 209\r\n
POST http://www.site.ru/news.html HTTP/1.0\r\n Content-Length: 209\r\n
Example news Content-Length: 209\r\n
Content-Disposition: form-data; name="news_file"; Content-Length: 209\r\n
filename="news.txt" Content-Length: 209\r\n
Content-Length: 209\r\n
Content-Type: application/octet-stream Content-Length: 209\r\n
Content-Disposition: form-data; name="password" Content-Length: 209\r\n

Content-Transfer-Encoding: binary

A very important point. Most CGI scripts are written by smart people, so they like to check the type of the incoming file, which is in the Content-Type. For what? Most often, uploading files on websites is used to receive images from the visitor. So, the browser itself tries to determine what kind of file the visitor wants to send and inserts the appropriate Content-Type into the request. The script checks it upon receipt, and, for example, if it is not a gif or jpeg, it ignores this file. Therefore, when creating a request “manually”, take care of the Content-Type value so that it is closest to the format of the transferred file.

In our example, a request is generated in which text file. A request for transferring a binary file is generated in the same way.

4. Postscript.

I think that it is not worth talking in detail about sending requests to the server. This is a matter of pure RHP technology :-). It is enough to carefully read the section on functions for working with sockets, or on the functions of the CURL module in the official PHP documentation.

From the above, I hope it is now clear why the question is: “How can I generate a POST request using the header function?” - meaningless.

The header(string) function adds an entry only to the request header, but not to the request body.

There is another type of request - Content-Type: multipart/mixed, I hope after reading this article you will easily understand this type yourself. You can study it in detail

This post is an answer to a question asked in one of my articles.

In this article I want to tell you what the HTTP methods GET/POST/PUT/DELETE and others are, why they were invented and how to use them in accordance with REST.

HTTP

So, what is one of the main protocols of the Internet? I’ll send the pedants to RFC2616, and I’ll tell the rest humanly :)

This protocol describes the interaction between two computers (client and server), built on the basis of messages called Request and Response. Each message consists of three parts: a start line, headers and a body. In this case, only the starting line is required.

The starting lines for the request and response have different formats - we are only interested in the starting line of the request, which looks like this: METHOD URI HTTP/ ,

VERSION Where METHOD is the HTTP request method, URI is the resource identifier, VERSION is the protocol version (for this moment

Headers are a collection of name-value pairs separated by a colon. The headers convey various service information: message encoding, browser name and version, address from which the client came (Referrer), and so on.

The body of the message is the actual data being transmitted. In the response, the transmitted data, as a rule, is the HTML page that the browser requested, and in the request, for example, in the body of the message, the contents of the files uploaded to the server are transmitted. But as a rule, there is no message body in the request at all.

HTTP Interaction Example

Let's look at an example.

Request:
GET /index.php HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text/html Connection: close
The first line is the query line, the rest are headers; message body is missing

Answer:
HTTP/1.0 200 OK Server: nginx/0.6.31 Content-Language: ru Content-Type: text/html; charset=utf-8 Content-Length: 1234 Connection: close ... THE HTML PAGE ITSELF...

Resources and Methods

Let's return to the starting line of the request and remember that it contains such a parameter as URI. This stands for Uniform Resource Identifier - a uniform resource identifier. A resource is, as a rule, a file on the server (an example URI in this case is “/styles.css”), but in general a resource can also be some abstract object (“/blogs/webdev/” - points to the “Web” block development" rather than on a specific file).

The HTTP request type (also called HTTP method) tells the server what action we want to perform on the resource. Initially (in the early 90s) it was assumed that the client could only want one thing from a resource - to receive it, but now using the HTTP protocol you can create posts, edit a profile, delete messages and much more. And these actions are difficult to combine with the term “receipt”.

To differentiate actions from resources at the level of HTTP methods, the following options were invented:

• GET - getting a resource
• POST - resource creation
• PUT - resource update
• DELETE - deleting a resource

Please note that the HTTP specification does not require the server to understand all methods (of which there are actually many more than 4) - only GET is required, and also does not tell the server what it should do when receiving a request with a particular method. This means that the server in response to the DELETE /index.php HTTP/1.1 request is not obliged to delete the index.php page on the server, the same as for a GET /index.php HTTP/1.1 request is not obliged to return the index.php page to you, it can delete it for example :)

REST comes into play

REST (REpresentational State Transfer) is a term introduced in 2000 by Roy Fielding, one of the developers of the HTTP protocol, as the name of a group of principles for building web applications. In general, REST covers a wider area than HTTP - it can also be used in other networks with other protocols. REST describes the principles of interaction between client and server, based on the concepts of “resource” and “verb” (can be understood as subject and predicate). In the case of HTTP, the resource is identified by its URI, and the verb is the HTTP method.

REST suggests abandoning the use of the same URI for different resources (that is, the addresses of two different articles like /index.php?article_id=10 and /index.php?article_id=20 - this is not a REST-way) and using different HTTP methods for different actions. That is, a web application written using the REST approach will delete a resource when accessing it with the HTTP DELETE method (of course, this does not mean that it is necessary to give the opportunity to delete everything and everyone, but any the application's delete request must use the HTTP DELETE method).

REST gives programmers the ability to write standardized and slightly prettier web applications than before. Using REST, the URI to add a new user will not be /user.php?action=create (GET/POST method), but simply /user.php (strictly POST method).

As a result, by combining the existing HTTP specification and the REST approach, various HTTP methods finally make sense. GET - returns a resource, POST - creates a new one, PUT - updates an existing one, DELETE - deletes it.

Problems?

Yes, there is a small problem with using REST in practice. This problem is called HTML.

PUT/DELETE requests can be sent using XMLHttpRequest, by contacting the server manually (say, via curl or even via telnet), but you cannot make an HTML form that sends a full-fledged PUT/DELETE request.

The thing is, the HTML specification doesn't allow you to create forms that submit data other than via GET or POST. Therefore, to work normally with other methods, you have to imitate them artificially. For example, in Rack (the mechanism on the basis of which Ruby interacts with the web server; Rails, Merb and other Ruby frameworks are made using Rack), you can add a hidden field to the form with the name "_method", and specify the name of the method as the value (e.g. "PUT") - in this case, a POST request will be sent, but Rack will be able to pretend that it received a PUT rather than a POST.