What is REST?

REpresentational State Transfer

REST, ou REpresentational State Transfer, é um estilo arquitetônico para fornecer padrões entre sistemas informáticos na web, tornando mais fácil para os sistemas se comunicarem uns com os outros. Sistemas REST-compliant, muitas vezes chamados de Sistemas RESTful, são caracterizados pela forma como eles são apátridas e separam as preocupações do cliente e servidor. Iremos analisar o que estes termos significam e porque são características benéficas para os Serviços na Web., a implementação do cliente e a implementação do servidor podem ser feitas de forma independente, sem que cada um saiba do outro. Isto significa que o código no lado do cliente pode ser alterado a qualquer momento sem afetar a operação do servidor, e o código no lado do servidor pode ser alterado sem afetar a operação do cliente.

desde que cada lado saiba que formato de Mensagens Enviar para o outro, elas podem ser mantidas modulares e separadas., Separando as preocupações de interface do usuário das preocupações de armazenamento de dados, melhoramos a flexibilidade da interface entre as plataformas e melhoramos a escalabilidade, simplificando os componentes do servidor. Além disso, a separação permite a cada componente a capacidade de evoluir independentemente.

usando uma interface de repouso, diferentes clientes atingem os mesmos objectivos de repouso, realizam as mesmas acções e recebem as mesmas respostas.,

apátridas

sistemas que seguem o paradigma do resto são apátridas, o que significa que o servidor não precisa saber nada sobre o estado em que o cliente está e vice-versa. Desta forma, tanto o servidor quanto o cliente podem entender qualquer mensagem recebida, mesmo sem ver mensagens anteriores. Esta restrição de apátridas é aplicada através do uso de recursos, em vez de comandos. Os recursos são os substantivos da Web-eles descrevem qualquer objeto, documento ou coisa que você pode precisar para armazenar ou enviar para outros serviços.,como os sistemas de repouso interagem através de operações padrão com recursos, eles não dependem da implementação de interfaces.

estas restrições ajudam aplicações RESTful alcançar confiabilidade, desempenho rápido e escalabilidade, como componentes que podem ser gerenciados, atualizados e reutilizados sem afetar o sistema como um todo, mesmo durante o funcionamento do sistema.

agora, vamos explorar como a comunicação entre o cliente e o servidor realmente acontece quando estamos implementando uma interface repousante.,

comunicação entre cliente e servidor

na arquitetura de resto, os clientes enviam pedidos para recuperar ou modificar recursos, e os servidores enviam respostas a estes pedidos. Vamos dar uma olhada nas formas padrão de fazer pedidos e enviar respostas.

fazer pedidos

repouso requer que um cliente faça um pedido ao servidor, a fim de obter ou modificar dados no servidor.,lient para repassar informações sobre o pedido

um caminho para um recurso

um corpo de mensagem opcional que contém dados

HTTP Verbos

Há 4 verbos HTTP básicos que usamos em pedidos para interagir com os recursos de um sistema de DESCANSO:

• GET — recuperar um recurso específico (por identificação) ou uma coleção de recursos
• PÓS — criar um novo recurso
• COLOQUE — a atualização de um recurso específico (por identificação)
• APAGAR — para remover um recurso específico por id

Você pode saber mais sobre estes verbos de HTTP no seguinte “Codeacademy” abaixo:

• o Que é CRUD?,

cabeçalhos e aceitar parâmetros

no cabeçalho da solicitação, o cliente envia o tipo de conteúdo que é capaz de receber do servidor. Isto é chamado de campo Accept, e garante que o servidor não envia dados que não podem ser compreendidos ou processados pelo cliente. As opções para os tipos de conteúdo são tipos MIME (ou extensões multi-usos de E-Mail da Internet, que você pode ler mais sobre os documentos web MDN.,

tipos MIME, utilizados para especificar os tipos de conteúdo no campo Accept, consistem num id

e num id

. Eles são separados por uma barra (/).

Por exemplo, um ficheiro de texto contendo HTML seria especificado com o tipo text/html. Se este ficheiro de texto contivesse CSS em vez disso, seria especificado como text/css. A generic text file would be denoted as . Este valor padrão, , não é um catch-all, no entanto., Se um cliente está esperando text/css e recebe text/plain, ele não será capaz de reconhecer o conteúdo.

Outros tipos e, comumente usado subtipos:

Por exemplo, um cliente acessar um recurso com id 23 em um articles recurso em um servidor pode enviar um pedido GET, como este:

Accept campo de cabeçalho, neste caso, está dizendo que o cliente vai aceitar o conteúdo de text/html ou application/xhtml.,

caminhos

pedidos devem conter um caminho para um recurso em que a operação deve ser realizada. Em APIs RESTful, paths deve ser projetado para ajudar o cliente a saber o que está acontecendo.

convencionalmente, a primeira parte do caminho deve ser a forma plural do recurso. Isso mantém os caminhos aninhados simples de ler e fácil de entender.

um caminho como fashionboutique.com/customers/223/orders/12 é claro no que aponta, mesmo que nunca tenha visto este caminho específico antes, porque é hierárquico e descritivo., Podemos ver que estamos acessando a ordem com id 12 para o cliente com id

Caminhos deve conter as informações necessárias para localizar um recurso com o grau de especificidade necessária. Quando se refere a uma lista ou coleta de recursos, nem sempre é necessário adicionar um id

. Por exemplo, um pedido de POST para o ID

path não precisaria de um identificador extra, como o servidor irá gerar um id

para o novo objeto.,

Se estamos tentando acessar um único recurso, precisaríamos adicionar um id

ao caminho.Por exemplo:GET fashionboutique.com/customers/:id— recupera o itemcustomersrecurso com oidespecificado.DELETE fashionboutique.com/customers/:id— exclui o itemcustomersrecurso com oidespecificado.,

Enviar Respostas

Tipos de Conteúdo

nos casos Em que o servidor está enviando uma carga de dados para o cliente, o servidor deve incluir uma tag content-type no cabeçalho da resposta. This content-type header field alertas the client to the type of data it is sending in the response body. Estes tipos de conteúdo são tipos MIME, assim como eles estão no campo accept do cabeçalho do pedido., The content-type that the server sends back in the response should be one of the options that the client specified in the accept field of the request.,

Por exemplo, quando um cliente está acessando um recurso com id 23 em um articles recurso com este Pedido:

O servidor pode enviar o conteúdo com o cabeçalho de resposta:

Isto significaria que o conteúdo pedido está sendo retornando no corpo da resposta com uma content-type de text/html, o que o cliente disse que seria capaz de aceitar.,

os códigos de resposta

as respostas do servidor contêm códigos de Estado para alertar o cliente para informações sobre o sucesso da operação. Como um desenvolvedor, você não precisa saber todos os código de status (existem muitos deles), mas você deve saber mais comuns e como eles são usados:

Para cada verbo HTTP, são esperados os códigos de status de um servidor deve retornar após o sucesso:

• OBTER retorno de 200 (OK)
• PÓS — retorno 201 (CRIADO)
• COLOQUE — o retorno de 200 (OK)
• APAGAR — retorno 204 (SEM CONTEÚDO)Se a operação falhar, voltar a maioria código de status específico possível correspondente para o problema que foi encontrado.,

exemplos de Pedidos e Respostas

digamos que temos uma aplicação que lhe permite ver, Criar, Editar e apagar clientes e encomendas para uma pequena loja de roupas hospedada em fashionboutique.com. Poderíamos criar uma API de HTTP que permite a um cliente para executar essas funções:

Se a gente queria ler todos os clientes, o pedido deve olhar como este:

Uma possível cabeçalho de resposta de como seria:

seguido de customers dados solicitados no application/json formato.,

Criar um novo cliente pelo lançamento de dados:

em seguida, O servidor gera um id para que o objeto e o retorna para o cliente, com um cabeçalho, como:

Para exibir um único cliente, nós OBTÊ-lo especificando o id de cliente:

Uma possível cabeçalho de resposta de como seria:

seguido dos dados para o customer recursos id 23 application/json formato.,

podemos actualização de cliente por COLOCAR ting os novos dados:

Uma possível resposta cabeçalho teria Status Code: 200 (OK), para notificar o cliente de que o item com id 123 foi modificado.

também podemos EXCLUIR que o cliente especificando o seu id:

A resposta teria um cabeçalho contendo Status Code: 204 (NO CONTENT), notificando o cliente que o item com id 123 foi excluído, e nada no corpo.,

prática com descanso

vamos imaginar que estamos construindo um local de coleta de fotos. Queremos fazer uma API para manter o controle dos usuários, locais e fotos desses locais. Este site tem um index.htmle umstyle.css. Cada usuário tem um nome de usuário e uma senha. Cada foto tem um local e um proprietário (ou seja, o usuário que tirou a foto). Cada local tem um nome e endereço de rua.,d=”229c60b6ce”>

Request-POST /venuesResponse-201 (CREATED)Content-type: application/json

Request-POST /venues/:id/photosResponse-201 (CREATED)Content-type: application/json

PUT Requests

Request-PUT /users/:idResponse-200 (OK)

Request-PUT /venues/:idResponse-200 (OK)

Request-PUT /venues/:id/photos/:idResponse-200 (OK)

DELETE Requests

Request-DELETE /venues/:idResponse-204 (NO CONTENT)

Request-DELETE /venues/:id/photos/:idResponse-204 (NO CONTENT)