It only makes sense to know what REST is, since RESTful is just the ability to do REST, that is, it is a grammatical question.

REST ignores component implementation details and protocol syntax in order to focus on the roles of components, restrictions on their interaction with other components, and their interpretation of meaningful data elements.

It has been officially defined by W3C .

Source: Wikipedia ( in English )

It is often applied to web services providing APIs for access to any service on the web. It fully uses HTTP messages to communicate through what is already defined in the protocol without having to "invent" new protocols specific to that application.

You essentially work with components, connectors, and data.

• It uses the HTTP protocol (verbs, accept headers, HTTP status codes, Content-Type ) explicitly and representatively to communicate. URIs are used to expose the structure of the service. Uses a common notation for data transfer like XML or JSON.
• It does not have state between these communications, that is, each communication is independent and uniform (standardized) needing to pass all necessary information.
• It should make it easier to cache content on the client.
• Must have clear definition of what is part of the client and server. The client does not need to know how the server stores data, for example. So each implementation does not depend on the other and becomes more scalable.
• Enables tiering, also facilitating scalability, reliability and security.
• It is often created with some form of extensibility.

Failing one of the first five items, the architecture can not be formally classified as RESTful. But not everyone sticks to formalism.

Example:

http://example.com/apagar/produto/1234

means that you are asking to delete the ID 1234 product.

Some say that this is wrong and since the emphasis is on resources rather than operations. Should use this:

http://example.com/produto/1234 (utilizando o verbo DELETE)

Let's agree that this can be useful for CRUD, but there are so many variations of what needs to be done that it is not possible to represent everything just with HTTP verbs. Okay, it's possible to make everything look CRUD, but maybe it requires additional information in the name of formalism.

All this is thought to provide better performance, scalability, simplicity, flexibility, visibility, portability and reliability.

Each defines how you want your API, as opposed to SOAP where everything is officially defined.

Canonical source in Dr. Roy Fielding's dissertation .

REST

Second Wikipedia :

  

It is intended as an application design image will behave.

That is, it would be something like, depending on how the same resource is consumed - a feature that can be identified visually inclusive - its behavior will change.

Let's illustrate to make it easier:

About HTTP requests

Every time we access something via browser , several requests are fired. When you access any page, a request for the content of that page is created. When this content returns, the browser mounts the page, but that page requires other resources like images, fonts, css >). For each resource, the browser will make a new request.

These requests consist mainly of three pieces of information:

• URL: Address that will receive the request;
• Verb / Method: Command to be done;
• Body: Information we send, such as data from a form, for example.

How many verbs, there are 4 that are most used:

• GET: Used to bring information
• POST: To create / add information
• PUT: To overload information
• DELETE: To delete information

RESTful Service

These are services that have REST behavior. That is, using the same design, your behavior will change according to the way it is consumed

For example, we have the URL ( endpoint ) below:

http://www.contoso.com/alunos

If we want to bring the list of students, we just make a request GET :

Request:
[GET] http://www.contoso.com/alunos
Body: empty

The answer will be something like:

Response:
HTTP Code 200 OK
[
    { id: 1, nome: "Thiago Lunardi" },
    { id: 2, nome: "Joe Satriani"}
]

But if I want to add a new student, I use the same design, but consuming otherwise, with request POST :

Request:
[POST] http://www.contoso.com/alunos
Body: { "nome: "Slash" }

HTTP Code 201 Created
{ id: 3, nome: "Slash" }

Continuing to learn more about a student:

Request:
[GET] http://www.contoso.com/alunos/1
Body: empty

Response:
HTTP Code 200 OK
{ 
    id: 1, 
    nome: "Thiago Lunardi",
    github: "https://github.com/ThiagoLunardi",
    website: "http://thiagolunardi.net",
    blog: "https://medium.com/@thiagolunardi",
}

In order to update a year's information, we use the same design, and only change the way we consume the resource, and it will have a different behavior:

Request:
[PUT] http://www.contoso.com/alunos/1
Body: { "twitter": "@thiagolunardi13" }

Response:
HTTP Code 200 OK
{ 
    id: 1, 
    nome: "Thiago Lunardi",
    github: "https://github.com/ThiagoLunardi",
    website: "http://thiagolunardi.net",
    blog: "https://medium.com/@thiagolunardi",
    twitter: "@thiagolunardi13"
}

To exclude:

Request:
[DELETE] http://www.contoso.com/alunos/1
Body: empty

Response:
HTTP Code 204 No Content