What is REST and Restful?

Question

I always hear of REST and RESTful, but I can’t tell the difference between us or what it’s for.

It seemed to me something with Common.js-style application architecture pattern.

Answer 1

It only makes sense to know what REST is, since Restful is just the ability to do REST, ie it’s a grammatical issue.

The Representational State Transfer (REST), in Portuguese Representational State Transfer, is an abstraction of the architecture of the World Wide Web, more precisely, is an architectural style consisting of a coordinated set of architectural constraints applied to components, connectors and data elements within a distributed hypermedia system.

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

He was 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 such as XML or JSON.
• There is no state between these communications, that is, each communication is independent and uniform (standardized) needing to pass all necessary information.
• It should facilitate content caching in the client.
• It must have a clear definition of what is part of the client and the 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.
• Allows layered use also facilitating scalability, reliability and security.
• It is often created with some form of extensibility.

Failing in one of the first five items, architecture cannot be formally classified as Restful. But not everyone clings to formalism.

Example:

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

means you are asking to erase the product from ID 1234.

Some say this is wrong and since the emphasis is on resources and not on operations. You should use it like this:

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

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

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

Each defines how you want your API, unlike SOAP where everything is set officially.

Canonical Source in the Dissertation of Dr. Roy Fielding.

Answer 2

REST

According to Wikipedia:

Is thought of as a design image of the application will behave.

That is, it would be something like, depending on how you consume the same resource - a feature that can be identified visually including - your behavior will change.

We will illustrate to facilitate:

About HTTP Requests

Every time we accessed something via browser (browser), several requisition are fired. When you access any page, a request for the content of that page is created. When that content returns, the browser mount (render) page, but this page requires other features like images, fonts, style sheets (css). For each resource, the browser will make a new request.

These requests are mainly composed of three pieces of information::

• URL: Address to receive the request;
• Verb/Method: Command you want done;
• Body: Information we send, such as form data, for example.

As for the Verbs, there are 4 which are the most used:

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

Restful Service

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

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

http://www.contoso.com/alunos

If we want to bring the list of students, 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, for more details 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",
}

To update one-year information in the same way, we use the same design, and just 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

Answer 3

The term REST means Representational STate Transfer.

It is nothing more than an architecture standard to create services and make them available on the Web. A service Restful is simply the one who carries out the implementation of this standard.

I mean, there’s no difference.

The term REST came up with Roy Fielding in a dissertation which he wrote in 2000. In this dissertation he classified a REST service with some characteristics. The main ones, I understand, would be:

• Client-server: On the one hand we have the server working with the data and on the other the client doing his interactions. This separation of responsibilities should be as clear as possible.
• Stateless (stateless): the client requests to the server must contain all the information. The server must not keep the client state (session) on its side.
• Cacheable: the server responses should determine whether that information can enter a cache or not. So the client can trust if that response can be used again in an equivalent request.
• Uniform interface: this item is related to the correct use of HTTP GET, POST, PUT, DELETE, etc verbs and a clear separation of resources and their levels.

That is, a REST service is not one that simply sends a Json back and forth. There are certain rules defined so that it can be easier to use, more reliable and with better performance.

An example that makes this clearer is when we compare two http services where one is based in REST and the other is not. Let’s start with an example of API that manages orders.

Request API: RPC with HTTP vs REST

PRC means Remote Procedure Call. It is a generic definition that is basically related to remote and synchronous requests (regardless of protocol). A simple HTTP call without observing any pattern can already be considered a RPC call.

Therefore, the best way I see to explain what is next to REST is to show an example that is far from REST.

RPC with HTTP

Let’s imagine that we want to create a new order using POST in an API RPC:

POST /pedidos

{
    "NovoPedido": {
          "nome": "Nome do Pedido",
          "valor": "9.99",
          "numero": "1001"
      }
} 

And to fetch the order by its identifier:

POST /pedidos

{
    "BuscarPedido": {
          "numero": "1001"
      }
} 

And, finally, remove the request would be:

POST /pedidos

{
    "RemoverPedido": {
          "numero": "1001"
      }
}

Well, this is not REST. We’re simply calling the same function with different parameters. It is unclear in the API that we have different ways to change the status of the "request".

Let’s see how the same example would look based on REST.

REST (or almost this...)

In a REST-based API we would have something like this to order:

POST /pedidos

{
  "nome": "Nome do Pedido",
  "valor": "9.99",
  "numero": "1001"
} 

Picking up the request by id wouldn’t even need one body in the request, we would only use the information present in the URL itself, passing the order identifier:

GET /pedidos/1001

And removing the request would look like the GET:

DELETE /pedidos/1001

And each of the above services would also return the corresponding HTTP status. In the case of POST would be a 201 CREATED (which means "success, resource was created"). In the case of GET would be a 200 OK ("success"). In the case of DELETE would be a 204 NO CONTENT ("success, with no content to return as a response").

However, the above examples still cannot be considered a Restful API. Note that in some moments I used the word "based" or "almost" to classify "Restibility" from the API of the previous example.

And why the above API is "based" on REST and not Restful?

Most developers believe that a Restful API stops in the above examples, but for an API to actually be considered Restful it should also apply the HATEOAS according to Roy himself:

if the engine of application state (and Hence the API) is not being driven by Hypertext, then it cannot be Restful and cannot be a REST API. Period.

I believe that this controversy of defining what is a REST API or did not end up generating maturity levels of a Rest API, given the difficulty (or even little need) of applying HATEOAS to Apis. These maturity levels can help developers understand where their Apis are right now and how far we can go with the API needs being developed.