Teoria REST API

O primeiro módulo terminou com a criação de um pedido HTTP, o seu envio, e a obtenção de uma resposta.

Faremos isto muitas mais vezes no futuro. Iremos enviar pedidos para servidores de terceiros. Faremos pedidos que eles próprios aceitam tais pedidos e devolveremos uma resposta. Iremos criar uma lógica complexa para processar pedidos.

Por conseguinte, seria bom estudar minuciosamente tudo relacionado com estes pedidos, para os analisar em pormenor. Para que não se possa apenas copiar o pedido em algum lugar e repeti-lo, mas realmente descobrir como tudo isto funciona.

Isto é o que faremos no segundo módulo. Vamos lá!

Teoria geral

Comecemos pela teoria.

Se fez o seu trabalho de casa no primeiro módulo e estudou a documentação, deveria ter notado a sigla API. Na verdade, é a documentação API que é a primeira coisa que os criadores devem estudar se quiserem compreender a interacção com algum serviço ou aplicação na rede.

API

API - Interface de Programação de Aplicações. Esta é uma descrição das formas em que o cliente e o servidor podem comunicar uns com os outros. Abrimos a documentação API e aprendemos a partir daí como obter os dados necessários do servidor.

Queremos sempre que esta interacção seja simples e compreensível. Isto simplifica a tarefa tanto para os programadores (não há necessidade de reinventar a roda ao conceber um novo serviço) como para os utilizadores (um serviço é muito mais fácil de aprender se funcionar com o mesmo princípio que os serviços anteriormente familiares). E aqui vale a pena recordar um novo termo - REST.

REST

REST - acrónimo de Representational State Transfer. Pode não soar muito claro, mas, dito de forma simples, REST é um estilo de interacção (troca de informação) entre um cliente e um servidor.

Isto não é um conjunto rígido de regras e requisitos. REST não força o uso de qualquer linguagem de programação em particular, nem vincula as mãos com directrizes estritas. REST é chamado um estilo arquitectónico e define 6 princípios que uma arquitectura de sistema deve cumprir.

Consequentemente, uma API desenvolvida tendo em conta os princípios de REST é chamada uma API REST, e as próprias aplicações são chamadas RESTful

Iremos criar precisamente tais aplicações RESTful, pelo que vale a pena discutir os princípios que elas cumprirão de imediato.

Princípios RESTful

Modelo Cliente-Servidor. O princípio define a separação entre o cliente e o servidor, a diferenciação das suas necessidades. O cliente não tem de se preocupar com a forma como os dados são armazenados, o principal é que estes sejam emitidos mediante pedido. Por sua vez, o servidor não se preocupa com o que o cliente vai fazer com estes dados, como processá-los e exibi-los posteriormente. Isto permite-lhes desenvolverem-se independentemente uns dos outros, e melhora a escalabilidade do sistema.

Apatridia. Este princípio significa que o servidor não deve "pensar" a resposta com base na experiência anterior com este cliente. Qualquer pedido é feito de modo a conter toda a informação necessária para o seu processamento, independentemente de pedidos anteriores.

Caching. Para minimizar os dados transmitidos, existe um mecanismo de cache. Por exemplo, se um logotipo for exibido em alguma página, então não faz sentido solicitá-lo ao servidor de cada vez. Não muda com tanta frequência, será suficiente obtê-lo uma vez e guardá-lo no computador do cliente, na cache. Mas se precisarmos de obter informações sobre a velocidade actual do carro, então a cache não ajudará de forma alguma. Este princípio determina que os dados transmitidos pelo servidor devem ser designados como "cacheable" ou não.

Interface uniforme. O princípio define um formato único de interacção cliente-servidor. A estrutura de todos os pedidos deve ser a mesma. Os dados devem ser enviados na mesma forma, independentemente de quem os solicite.

Sistema em camadas. O cliente e o servidor não comunicam necessariamente directamente. A transmissão de dados pode passar por vários nós intermédios. Neste caso, o sistema é concebido de modo a que nem o cliente nem o servidor saibam se estão a interagir com a aplicação final ou com um nó intermédio. Isto permite equilibrar a carga nos servidores, aumentar a escalabilidade.

Código a pedido (opcional). O único princípio que não é obrigatório. De acordo com ele, o cliente pode expandir a sua funcionalidade descarregando código executável do servidor (por exemplo, scripts). Neste caso, o código deve ser executado apenas a pedido.