Introdução ao REST

8.1 Abordagem API remota

Todos os programadores cometem o mesmo erro ao construir uma arquitetura cliente-servidor. Eles começam a tratar as solicitações ao servidor como chamadas de método .

Você deseja iniciar o processo de geração de relatórios no servidor, por que não enviar uma solicitação como:

http://server.com/startDocumentGeneration?params

E como baixar o relatório após a conclusão? Para fazer isso, vamos escrever outro método:

http://server.com/getDocument

O servidor armazena HttpSessioninformações em nosso documento e, assim que o documento for gerado, o servidor o devolverá.

Ótima abordagem. Ou não?

A abordagem é realmente terrível. O fato é que o servidor deve se lembrar do número do documento. Em outras palavras, para processar adequadamente novas chamadas de método, o servidor deve se lembrar dos resultados da chamada de métodos anteriores.

Na web, isso é um grande problema. A Internet pode desaparecer, o navegador pode fechar. A página pode ser recarregada ou clicada acidentalmente em um link e assim por diante. E o servidor continuará armazenando megabytes de dados de solicitações anteriores do usuário ...

Para um trabalho confortável com o servidor, você não pode esperar que sempre tenha em mãos os dados das solicitações anteriores ao servidor.

Como então chamar métodos do servidor? A resposta correta seria terrível: de jeito nenhum!

8.2 Abordagem REST

Os programadores voltaram ao básico e lembraram que inicialmente a requisição continha o caminho para o arquivo no servidor:

http://server.com/path?params

E decidimos usar essa abordagem ao máximo.

Agora o servidor é considerado como um repositório de dados visíveis para o exterior na forma de uma árvore .

Se você deseja obter uma lista de todos os usuários, chame a consulta:

http://server.com/users

Se você deseja obter dados do usuário 113, execute a consulta:

http://server.com/users/113

E assim por diante, tudo na mesma linha.

Mais uma vez, o servidor é visto como um repositório de dados visíveis para o exterior na forma de uma árvore.

Os dados podem ser pedidos recebidos - GET , pedidos POST modificados e pedidos excluídos - DELETE .

8.3 Nenhum estado

O protocolo REST de interação entre o cliente e o servidor exige a seguinte condição: durante o período entre as solicitações do cliente, nenhuma informação sobre o estado do cliente é armazenada no servidor.

Todas as solicitações do cliente devem ser elaboradas de forma que o servidor receba todas as informações necessárias para atender à solicitação a cada vez . O estado da sessão é salvo no lado do cliente.

Durante o processamento das solicitações do cliente, o cliente é considerado em um estado de transição. Cada estado de aplicativo individual é representado por links que podem ser invocados na próxima vez que o cliente acessar.

8.4 Uniformidade da interface

Todos os caminhos usados ​​para recuperar objetos do servidor são padronizados. Isso é muito conveniente, especialmente se você estiver obtendo dados de outros servidores REST.

Todas as interfaces de objetos devem atender a três condições:

Identificação do recurso

Todos os recursos são identificados em solicitações usando um URI. Os recursos dentro do servidor são separados das exibições que são retornadas aos clientes. Por exemplo, um servidor pode enviar dados de um banco de dados como HTML, XML ou JSON, nenhum dos quais é um tipo de armazenamento dentro do servidor.

Manipulando recursos por meio de uma exibição

Se o cliente armazenar uma representação do recurso, incluindo metadados, ele terá informações suficientes para modificar ou excluir o recurso no servidor.

Mensagens "autodescritivas"

Cada mensagem contém informações suficientes para entender como processá-la. Por exemplo, se você precisar de informações sobre o usuário, o servidor retornará um objeto JSON, onde haverá campos de nome e endereço.

Não deve haver uma situação em que o cliente precise saber que o primeiro número na resposta é a idade e o segundo é a data de nascimento.

8.5 Cache

A abordagem REST assume que as solicitações de dados são feitas por meio do protocolo HTTP. Portanto, os objetos são obtidos chamando uma solicitação GET. Isso significa que eles, como todos os recursos recebidos por meio de uma solicitação GET, estão sujeitos a todas as regras de cache de recursos HTTP.

Ou seja, os dados recebidos por meio da API REST são armazenados em cache da mesma forma que quaisquer recursos estáticos em servidores da Web. Beleza :)