REST é um conjunto de princípios que definem como Web Standards como

HTTP e URIs devem ser usados (o que frequentemente difere um pouco do

que muitas pessoas atualmente fazem). A promessa é que se você aderir a
princípios REST enquanto estiver desenhando sua aplicação, você terá um
sistema que explora a arquitetura da Web em seu benefício.
A utilização da arquitetura REST, portanto, permite a comunicação entre
aplicações. Ao abrir o navegador, ele estabelece uma conexão TCP/IP com o
servidor de destino e envia uma requisição GET HTTP, com o endereço
buscado.
O servidor, então, interpreta a requisição, retornando com uma resposta HTTP
ao navegador. Essa resposta pode ser completa, com representações em
formato HTML, ou apresentar erro, afirmando que o recurso solicitado não foi
encontrado.
Os Web Services que adotam REST são mais leves e perfeitos na busca
da metodologia ágil. Outro diferencial é a flexibilidade, sendo possível escolher
o formato que melhor se encaixa para as mensagens do sistema. Os mais
utilizados, além do texto puro, são Json e XML, dependendo da necessidade
de cada momento.
A ideia principal do REST é representar recursos disponíveis numa relação
simples de cliente-servidor, onde esses recursos, ou coleções de recursos,
podem ser potencialmente modificados através de ações feitas sobre a
transação REST (utilizando os verbos HTTP) e essas transações são stateless,
ou seja, não são persistidas sessões entre ela e o estado necessário para lidar
com a solicitação está contido dentro da própria solicitação, seja como parte do
URI, parâmetros de string de consulta, corpo ou cabeçalhos.

A arquitetura REST foi popularizada basicamente depois que Facebook e

Twitter (não só eles, é claro) publicaram suas APIs abertas seguindo este
padrão. Bem, não seguiam exatamente todos os padrões da arquitetura, mas
eram, em sua essência, REST.

APIs RESTful são usadas por sites como Google, Amazon, LinkedIn e
Twitter.

O uso de boas práticas de programação aliado a um modelo arquitetural

simplista e robusto podem reduzir drasticamente o tempo necessário para
construir tais sistemas. Neste sentido, o REST (Representational State
Transfer) apresenta-se como um modelo arquitetural poderoso e
suficientemente maduro, capaz de atender requisitos complexos de integração
sem agregar complexidade e excesso de acoplamento.

Utilizando-se de tecnologias já consagradas e de grande penetração no

mercado, o modelo arquitetural REST visa orientar o desenvolvimento de uma
aplicação dentro de uma filosofia “WEB-Like”, fortemente baseada nos
fundamentos de funcionamento da WEB, em especial, do protocolo HTTP
(Hypertext Transfer Protocol). REST ganhou notoriedade por ser um estilo
arquitetural simplista e ao mesmo tempo poderoso. Isso despertou o interesse
da comunidade Java que, por meio da JCP (Java Community Process), iniciou
um processo para padronização técnica deste modelo dentro da plataforma.

Para que serve o Rest API?

Há uma grande variação sobre as formas de utilização das APIs. As redes
sociais, por exemplo, fornecem APIs que podem ser utilizadas em outros sites
para recuperar as informações de uma página. Existem vários plugins
em WordPress que acessam as redes sociais por meio delas e transformam o
resultado dessa interação em pequenas visualizações do estado atual da
página correspondente.
Dessa forma, se um usuário quiser curtir a página, por exemplo, não é
necessário sair do site original para essa ação. Ao clicar no botão curtir, há
uma chamada via API para concluir essa operação. Para que isso seja
possível, as redes sociais disponibilizam um token com a devida autorização de
modo que a API tenha acesso às informações.
Assim como as redes sociais, as APIs também são utilizadas em sites
de E-commerce para acessar as intermediadoras de pagamento e concluir as
operações de compras. Portanto, a API serve para a comunicação entre
aplicações para a troca de informações de maneira rápida e segura.

Quais as vantagens de utilizar o Rest API?

1)Separação entre o cliente e servidor

Uma das vantagens de utilizar o modelo Rest API é a separação entre as

aplicações front-end e back-end. Isso é importante para proteger o
armazenamento de dados, pois não há o tratamento de regras de negócio,
ou seja, é feita apenas a troca de informações seja para recuperar dados,
seja para inserir ou deletar novos registros.

2)Mais visibilidade, confiabilidade e escalabilidade

Por ter a separação cliente / servidor, há muito mais facilidade durante o

desenvolvimento da aplicação. Isso porque ela pode ser facilmente
escalada, já que há não há dificuldade para acoplar recursos. Como cada
requisição é feita de maneira única e independente, é possível mudar uma
requisição para outro DNS, sem que isso interfira na aplicação.
Em outras palavras, a API permite que a aplicação acesse banco de dados
de diferentes servidores, o que muitas vezes é importante para o
desenvolvimento em grandes aplicações. Portanto, sua utilização garante
mais visibilidade e confiabilidade ao utilizar esses recursos.

3)Multiplataforma
 As requisições HTTP feitas em uma Rest API retornam dados no formato
JSON. Vale ressaltar que existem outros formatos possíveis de retorno,
como o XML, entretanto, o JSON é o mais utilizado. Portanto, a maioria
dos sites que trabalha sob esse modelo recebe esse formato de dados.
Essa característica é essencial para o desenvolvimento de aplicações
multiplataformas. Isso porque, ao receber os dados nesse formato, a
camada front-end da aplicação é capaz de fazer o tratamento adequado
para a exibição dos resultados de acordo com o tipo de dispositivo
utilizado.
A utilização de Rest API é importante para adicionar diversas
funcionalidades ao site. Suas características permitem a integração com
diferentes aplicações; entre elas, as redes sociais e os sistemas de
pagamento. Por isso, é uma tecnologia que garante maior confiabilidade e
escalabilidade, além de facilitar o desenvolvimento de aplicações
multiplataformas.

Contudo, o uso do modelo REST deve ser adequadamente estudado, suas vantagens
e desvantagens devem ser pesadas para que, ao final, os resultados para o projeto
sejam realmente positivos.

Dentre os diversos pontos onde temos vantagens em utilizar REST, os pontos

de maior destaque são:​

–Agilidade: Um dos fatores que é mais levado em conta na decisão por

implementar serviços REST, se dá ao fato da necessidade que temos de que
sistemas estejam sempre disponíveis e que tenham processamento rápido de
requisições.
Essas implementações normalmente são mais leves, devido ao REST ser um
protocolo sem estado e seguir sempre os mesmos padrões,
consequentemente, integrações serão mais rápidas e não afetam o sistema
como um todo, mesmo que em execução.
– Flexibilidade: Os bodies podem ser implementados usando de várias
sintaxes distintas, como: XML, JSON, e RSS. O desenvolvedor, pode optar
pelo formato mais adequado ao tipo de mensagens trocadas pelo sistema de
acordo com a sua necessidade, garantindo uma certa flexibilidade durante o
desenvolvimento de serviços.
– Praticidade: Este é um ponto bem interessante para quem adere ao REST,
dentre os diversos motivos que reforçam esta opção, destacam-se:
Qual a diferença entre REST API e um Webservice ‘normal’?

Ambos funcionam como uma forma de comunicação. A grande diferente é que

um Webservice facilita a interação entre duas maquinas, enquanto que uma
API atua como uma interface entre duas aplicações diferentes, para que elas
possam realizar integrações e se comunicar.

Quando um Webservice é concebido, ele (geralmente) utiliza uma interface que

pode ser compreendida por outra maquina através da implementação de
padrões como o WSDL (Webservice Description Language). Já a API define a
forma com que um programa se comunica com outro. Ele pode implementar
também SOAP, REST e XML-RPC (chamadas remotas utilizando XML) como
uma forma de comunicação.

Geralmente estas comunicações (entre API’s) são feitas via HTTP, mas isso
não é um requisito. O Office utuliza VBA e APIs baseadas em objetos COM
para se comunicar, que não utiliza o protocolo HTTP. Outras formas de
comunicação utilizadas são objetos COM, DLLs (arquivos .H no C/C++) e
arquivos .JAR ou RMI (Java).

Resumindo, um Webservice é uma forma de se disponibilizar a API rest,

utilizando HTTP como forma de comunicação.

​
As restrições do REST (Arquitetura usada)
1. Client-Server
É a restrição básica para uma aplicação REST. O objetivo desta divisão é
separar a arquiterura e responsabilidades em dois ambientes. Assim, o cliente
(consumidor do serviço) não se preocupa com tarefas do tipo: comunicação
com banco de dados, gerenciamento de cache, log, etc. E o contrário também
é válido, o servidor (provedor do serviço) não se preocupa com tarefas como:
interface, experiência do usuário, etc. Permitindo, assim, a evolução
independente das duas arquiteturas.

Neste modelo, o servidor espera pelas requisições do cliente, executa estas

requests e devolve uma resposta.
 2. Stateless
Um mesmo cliente pode mandar várias requisições para o servidor, porém,
cada uma delas devem ser independentes, ou seja, toda requisição deve
conter todas as informações necessárias para que o servidor consiga
entendê-la e processá-la adequatamente.

Neste caso, o servidor não deve guardar nenhuma informação a respeito do

estado do cliente. Qualquer informação de estado deve ficar no cliente, como
as sessões, por exemplo.

3. Cacheable
Como muitos clientes acessam um mesmo servidor, e muitas vezes
requisitando os mesmos recursos, é necessário que estas respostas possam
ser cacheadas, evitando processamento desnecessário e aumentando
significativamente a performance.

Isso significa que um primeiro cliente solicita um determinado resource para o

servidor, o servidor processa esta requisição e armazena isso temporariamente
no cache. Quando os demais clientes solicitam o mesmo resource, o servidor
devolve o que está no cache sem ter que reprocessá-lo. A regra para limpar o
cache varia de resource para resource, pode ser limpo sempre que houver uma
troca de estado no resource; pode ser limpo em um determinado intervalo de
tempo antes de ser reprocessado, de hora em hora, por exemplo, e por aí vai.

4. Uniform Interface
É, basicamente, um contrato para comunicação entre clientes e servidor. São
pequenas regras para deixar um componente o mais genérico possível, o
tornando muito mais fácil de ser refatorado e melhorado.

●​ Identificar os recursos (URI)

●​ Manipular recursos através de representações (Verbos HTTP).
●​ Mensagens auto-descritivas, cada requisição deve conter informações
suficientes para o server processar a informação.
●​ HATEOAS - Hypermedia As The Engine Of Application State. Esta restrição diz
que a response deve conter links de conteúdos relacionados ao resource

5. Layered System
A sua aplicação deve ser composta por camadas, e estas camadas devem ser
fáceis de alterar, tanto para adicionar mais camadas, quanto para removê-las.
Dito isso, um dos princípios desta restrição é que o cliente nunca deve chamar
diretamente o servidor da aplicação sem antes passar por um intermediador, no
caso, pode ser um load balancer ou qualquer outra máquina que faça a
interface com o(s) servidor(es). Isso garante que o cliente se preocupe apenas
com a comunicação com o intermediador e o intermediador fica responsável
por distribuir as requições nos servidores, seja um ou mais, indifere nesse
caso. O importante é ficar claro que criando um intermediador, a sua estrutura
fica muito mais flexível à mudanças.

6. Code-On-Demand (Opcional)
Esta condição permite que o cliente possa executar algum código sob
demanda, ou seja, estender parte da lógica do servidor para o cliente, seja
através de um applet ou scripts. Assim, diferentes clientes podem se comportar
de maneiras específicas mesmo que utilizando exatamente os mesmos
serviços providos pelo servidor.

Como este item não faz parte da arquitetura em si, ele é considerado opcional.
Ele pode ser utilizado quando executar alguma parte do serviço do lado do
cliente for mais eficaz ou rápida.
Resources

O REST é Resource Based. Esse termo irei tratar com o nome em inglês pois é
um item chave dentro do conceito.

Um Resource é a chave da abstração no REST. Um resource é qualquer coisa

importante o suficiente para ser referenciado com um nome. O REST usa um
URI (Uniform Resource Identifier) para identificar o resource. Resource é
qualquer coisa que possa ter uma URI.
REST e RESTful são a mesma coisa?

●​

Boas práticas para o REST

Ao lidar com o restful Web services, o esperado é que, ao construir

aplicações, o usuário conte com um sistema que explora a arquitetura da Web
em seu benefício. Entre as ações fundamentais que você deve se ater dentro
dessa rotina, podemos citar:

●​ Determinar um identificador para todas as coisas;

●​ Vincular e dar interação as coisas;
●​ Usar métodos que possuam um padrão;
●​ Definir recursos com representações variadas,
●​ Dar prioridade a uma comunicação sem estado.
Sobre Requisições HTTP

Toda as vezes que acessamos algo via browser (navegador),

várias requisicões são disparadas. Quando acessa uma página qualquer, uma
requisição pelo conteúdo dessa página é criado. Quando esse conteúdo
retornar, o browser monta (renderiza) a página, mas essa página requer outros
recursos como imagens, fontes, folhas de estilo (css). Para cada recurso, o
navegador irá fazer uma nova requisição.
Essas requisições são compostas, principalmente, de três informações:

●​ URL: Endereço que irá receber a requisição;

●​ Verbo/Método: Comando que se deseja que seja feito;
●​ Corpo: Informações que enviamos, como dados de um formulário, por
exemplo.
Quantos aos Verbos, existem 4 que são os mais utilizados:

●​ GET: Usado para trazer informações

●​ POST: Para criar/adicionar informações
●​ PUT: Para atualizar informações
●​ DELETE: Para excluir informações

Resposta
​
Baseado nos métodos que discutimos, o servidor deve processar cada
uma das requisições e retornar uma resposta adequada. Veja um resumo
de cada uma dessas respostas.
1XX – Informações Gerais
2XX – Sucesso
3XX – Redirecionamento
4XX – Erro no cliente
5XX – Erro no servidor
Para cada tipo que você pode ver, existe uma série de respostas
relacionadas. Por exemplo, se o servidor retornar um “200 OK”, significa
que o recurso pedido foi retornado com sucesso.
Por outro lado, se o servidor retornar um “404 Not Found”, significa que o
recurso que estamos pedindo não foi encontrado.
​

Serviço RESTful

São serviços que possuem comportamento REST., Ou seja, usando o mesmo

design, seu comportamento irá mudar de acordo com a maneira que é
consumido

Por exemplo, temos a URL (endpoint) abaixo:

http://www.contoso.com/alunos
​
Se queremos trazer a lista de alunos, basta realizamos uma requisição GET:
Request:​

[GET] http://www.contoso.com/alunos
Body: empty
A resposta será algo como:

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

Mas, se eu quiser adicionar um novo aluno, uso o mesmo design, mas

consumindo de outra forma, com requisição POST:

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

HTTP Code 201 Created

{ id: 3, nome: "Slash" }

Continuando, para saber mais detalhes sobre um aluno:

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",
}

Para atualizar informações de um ano, da mesma forma, usamos o mesmo

design, e apenas mudamos a forma de consumir o recurso, e ele terá um
comportamento diferente:

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"
}

Para excluir:

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

Response:
HTTP Code 204 No Content

Referencias

https://pt.stackoverflow.com/questions/45783/o-que-%C3%A9-rest-e-restful/45787

https://www.totvs.com/blog/developers/rest/

https://www.devmedia.com.br/conhecendo-o-modelo-arquitetural-rest/28052

https://imasters.com.br/desenvolvimento/definicao-restricoes-e-beneficios-modelo-de-arquite
tura-rest

https://rockcontent.com/blog/rest-api/