What is REST, RESTFul, and CRUD

REST is a concept for component interaction based on the HTTP protocol. I do not want to dwell on boring theory, but I will give a simple explanation in relation to sites.

On the Web, the exchange takes place over the HTTP protocol: request-response. In order to transmit some data, they need to be identified somehow, that is, their "sign", "action" or something similar must be indicated. And therefore, before, the data needed to be formatted in some kind of complex format, usually XML or JSON.

So, REST says that this is not necessary. We transfer the data as is, only the method (parameter) for this data is specified for the HTTP request. We usually operate on GET and POST because they work out of the box in HTML and are supported by any browser. But in fact, the HTTP method can be absolutely anything. There are some common ones: PUT, DELETE, OPTIONS, PATCH, but this is not a standard at all.

That is, for example, we want to send a GET request to the server at the address site/task and get a list of tasks (tasks). Then we want to add a new task: we send the site/task to the same address but using the POST method. Then we decided that in order to edit the task, we need to send PUT and again to the same address. And, if such booze has gone, then we also send the DELETE method to delete some tasks.

Forming a GET request is very simple - just type the address in the browser. POST already needs an HTML form with method=post. These same methods work great through AJAX as well. But as far as PUT and DELETE are concerned, neither HTML nor the browser knows anything about them. Formally, we can still specify them, but we will stumble upon the last wall - the server, which also usually does not know anything about these methods and is cut with a 501 or 405 error.

Thus, although HTTP supports arbitrary methods, only two actually work: GET and POST.

To get around this limitation and apply REST to our sites, we came up with a trick. All "non-standard" requests in their body must contain a separate field, where the "desired" method is indicated.

Well-established practice is to specify a method in a _methodform field or an Ajax request.

<form  method = "POST" > 
	<input  type = "hidden"  name = "_method"  value = "PUT" >
	... other form data ...
</form>

That is, the real sending is POST, but the application checks the field _methodand uses it to decide what to do next.

This parsing is performed by the application router. If so, then the routing rules are specified something like this:

[ 
    'method'  =>  'POST' ,  // create new task (Create) 
    'pattern'  =>  'task' , 
    'action'  =>  '\Controller\Task\Task@create' , 
], 
[ 
    'method'  = >  'GET' ,  // task show (Read) 
    'pattern'  =>  'task' , 
    'action'  =>  '\Controller\Task\Task@read' , 
], 
[ 
    'method'  =>  'PUT' ,  / /update/edit task (Update) 
    'pattern'  =>  'task' , 
    'action'  => '\Controller\Task\Task@update' , 
], 
[ 
    'method'  =>  'DELETE' ,  // delete task (Delete) 
    'pattern'  =>  'task' , 
    'action'  =>  '\Controller\Task\ Task@delete' , 
]

Please note that in all cases one HTTP address is used: site/task - only methods that are specified either in the HTML form or in the Ajax request change.

Here we come to another concept - CRUD, which is nothing but an abbreviation for Create, Read, Update, Delete - Create, Read, Update, Delete. These are nothing more than basic operations for the vast majority of data.

CRUD is needed in order to divide the program code into separate parts, each of which is responsible for its own actions. In this example, a PHP class will be used \Controller\Task\Task, where each HTTP method will be executed by its own PHP method:

• for POST the method will be executedcreate()
• for GET method will be executedread()
• for PUT the method will be executedupdate()
• for DELETE method will be executeddelete()

If you do not use REST, then most likely you would have to specify the action either at a separate url address or in get parameters. Something like this:

• site/task/create
• site/task/update/7
• site/task/delete/5
• site/task?action=create
• site/task?action=update&id=7
• site/task?action=delete&id=5

REST, of course, requires at least some kind of routing that can understand _method. In general, it will be like this:

$method  =  'get' ;  // default method
 
if  ( $_POST )  { 
    if  ( isset ( $_POST [ '_method' ]))  
        $method  =  $_POST [ '_method' ]; 
    else  
        $method  =  'post' ; 
} 
...

Then the router looks at the rules and finds a PHP method to run.

REST is just a concept, a set of rules. If we apply these rules to the application, we are already talking about RESTFul. For example, REST assumes the use of a client-server model. If we assume that the server is a real hosting server and the client is a site user, then for RESTFul we need to configure the real server so that it understands the HTTP methods used. It is unlikely that anyone will do this, so, from this point of view, the application cannot be considered RESTFul.

But, on the other hand, if the REST server is just an abstraction, then what difference does it make to us how a real server works at all if its main task is simply to give and receive what we need? Even if we use the trick with _method, it works as expected, which means the application is RESTFul compliant.

In general, it is worth noting that now REST and RESTFul are actually synonyms. If a PHP application can accept an HTTP method in any way, then it is considered that this is already a full-fledged RESTFul. You just need to understand that the REST architecture allows us to use HTTP in much the same way as it was originally intended.