O documento define REST como um estilo arquitetônico baseado na transferência de representações de estado entre cliente e servidor para avançar o estado de um aplicativo. REST impõe restrições como cliente-servidor sem estado, interface uniforme e sistema de camadas para permitir propriedades como desempenho, escalabilidade e portabilidade. REST normalmente usa HTTP como protocolo de transferência, com verbos como GET e POST, códigos de status e cabeçalhos para construir APIs web apátridas, escaláveis e simples.

1. Rest Introdução
Definição
O termo REST significa "Transferência de Estado de representação." A
definição formal possível de que poderia ser como segue.
estilo API arquitetônico baseado em transferência de uma representação do
estado (documentos) entre cliente e servidor, a fim de avançar o estado de
um aplicativo.
Restrições
Para considerar os pedidos como RESTful, os aplicativos precisam estar
em conformidade com as seguintes restrições REST. Cumprindo com as
restrições permite que um sistema hipermídia distribuído para ter as
seguintes propriedades desejáveis não-funcionais: desempenho,
escalabilidade, simplicidade, extensibilidade, visibilidade, portabilidade e
confiabilidade.
Servidor cliente
Um modelo cliente-servidor favorece a separação de interesses para que os
clientes não estão preocupados com o armazenamento de dados. Assim, a
portabilidade de código clientes é melhorada. Por outro lado, o servidor não
está preocupado com a interface de utilizador ou estado do utilizador, para
que o servidor possa ser mais simples e mais escalável. Servidores e
clientes podem ser desenvolvidos de forma independente, desde que
estejam em conformidade com o contrato definido.
Stateless
contexto de cliente nunca é armazenado no servidor entre as solicitações.
Cada pedido tem de conter todas as informações necessárias. Um servidor
sem estado melhora a escalabilidade, permitindo que o servidor para
recursos rapidamente livres e simplifica a implementação. Confiabilidade
facilita a recuperação de falhas parciais. Visibilidade, sistema de
monitorização não tem que olhar para além de um único pedido para
determinar a natureza do pedido.
Uma das desvantagens de ter um servidor é diminuída sem estado de
desempenho da rede, como todos os dados necessários tem de ser enviado
em cada pedido.

2. Interface uniforme
Usando uma interface uniforme simplifica e desacopla a arquitetura e
favorece a evolução independente de partes diferentes. Como explicado
mais adiante neste post, URIs, recursos e ajuda hipermídia para produzir
uma interface padrão que melhora a visibilidade das interações, simplifica a
arquitetura geral do sistema e incentivar a evolução independente. O trade-
off é que ele degrada a eficiência já que a informação é transferida em um
formato padrão, em vez de um que é especial às necessidades de um
aplicativo.
Sistema de camadas
Usando um sistema em camadas reduz a complexidade, restringir o seu
comportamento componente de tal forma que cada elemento não pode
acessar além de sua camada de imediato. Favorece a independência
substrato, restringindo o conhecimento de outras partes do sistema. As
camadas podem encapsular componentes legados e proteger novos serviços
de clientes legados. Intermediários podem ser usados para melhorar a
escalabilidade, permitindo que o balanceamento de carga através das redes.
A principal desvantagem é que os sistemas em camadas adicionar uma
sobrecarga e latência para o processamento de dados, portanto, reduzindo o
desempenho percebido pelo usuário.
Code-On-Demand (Opcional)
RESTO permite que os clientes para estender sua funcionalidade fazendo o
download e execução de scripts de código. Isto simplifica e melhora a
extensibilidade clientes. Por outro lado, reduz a visibilidade, o que é por
isso que ele é apenas uma restrição opcional.
elementos
DESCANSO tem vários elementos na sua caixa de ferramentas para
construir apátridas, escaláveis e simples APIs web.
HTTP
recursos
URIs
hipermídia
HTTP - Documento de Protocolo de Transferência de Aplicação
RESTO é normalmente usado junto com HTTP como seu protocolo de
transferência, uma vez que oferece várias vantagens. Entre eles estão os
verbos de HTTP, códigos de status e cabeçalhos.

3. Verbos
Em vez de definir novos verbos para cada comportamento possível em
nosso serviço web, o HTTP introduz um conjunto padrão de verbos para
lidar com situações semelhantes, da mesma forma, a remoção de variação
desnecessária e criando uma API mais intuitiva. Cada verbo tem uma
combinação diferente de duas propriedades que as tornam adequadas para
diferentes cenários.
Idempotente: A operação pode ser repetida em caso de falhas.
Seguro: A operação não tem efeitos colaterais para o qual o cliente é
responsável.
GET
Usado para ler o estado do servidor. Sendo uma operação segura, ele pode
ser executado várias vezes, sem risco de modificação de dados ou
corrupção - chamando-o de uma vez tem o mesmo efeito que chamá-lo dez
vezes. Como uma operação idempotente, fazendo vários pedidos idênticos
tem o mesmo resultado como um único pedido.
POST
Normalmente usado para criar algum estado no servidor. É seguro nem
idempotente. Portanto várias solicitações irá criar vários recursos no
servidor. Como uma operação não-idempotent, POST não deve ser
utilizado para operações que lidam com dinheiro, como no caso de um
pedido não é feito várias vezes, que poderia potencialmente ser a
transferência de dinheiro ou pagar várias vezes.
PUT
É principalmente utilizado para atualizar estado no servidor, embora
também possa ser utilizado para criar estado. É idempotent mas não segura
como ela muda o estado do servidor. Sendo um idempotent fez colocar um
bom candidato, por exemplo, para as operações relacionadas com dinheiro.
DELETE

4. É usado para eliminar estado no servidor. É idempotentmas não seguro,
uma vez que remove o estado do servidor. É idempotentes como apagar
estado que foi excluído anteriormente não deve ter outras implicações.
RESPONSE STATUS CODE
Os códigos de estado de HTTP fornecer metadados na resposta ao estado
dos recursos solicitados. Eles são parte do que torna a web uma plataforma
para a construção de sistemas distribuídos.
Eles estão divididos nas seguintes categorias:
1xx - Metadados.
2xx - Está tudo bem.
3xx - Redirecionamento.
4xx - Cliente fez algo errado.
5xx - Servidor fez algo errado.
HEADER
Os cabeçalhos HTTP são componentes para passar informações adicionais
em pedidos e respostas. Cabeçalhos consistem de um nome de maiúsculas e
minúsculas seguido por dois pontos e seu valor. Cabeçalhos poderiam ser
agrupadas como: cabeçalhos gerais: aplicam-se tanto solicitações e
respostas, mas não há relação aos dados transmitidos no corpo. Cabeçalhos
de solicitação: contêm mais informações sobre o recurso a ser obtido ou
sobre o cliente que fez o pedido. cabeçalhos de resposta: contêm
informações adicionais sobre a resposta. cabeçalhos de entidade: Adicionar
informações sobre o corpo da entidade, como o índice de comprimento ou
do tipo MIME.