Características dos serviços REST

REST não é um padrão, simplesmente define alguns princípios de arquitetura a seguir para implementar aplicações ou serviços em rede. No entanto, o REST baseia-se em padrões para a sua implementação: HTTP, XML, etc. Os serviços REST têm as seguintes características:

Cliente-Servidor
Os serviços REST devem ser baseados numa arquitetura Cliente-Servidor. Um servidor que contém os recursos e estados dos mesmos, e clientes que acedem aos mesmos.

Sem estado
Os Serviços REST podem ser escalados até atingir grandes desempenhos para abranger a procura de todos os possíveis clientes. Isto implica que seja necessário criar farms de servidores com balanceamento de cargas e failover ou diferentes níveis de servidores para minimizar o tempo de resposta aos clientes. Ao utilizar servidores intermédios, é necessário que os clientes REST enviem a informação completa e independente em cada solicitação de estado de um recurso. Desta forma, os servidores intermédios podem reencaminhar, encaminhar, balancear sem necessidade de que os servidores troquem informações de sessões de clientes.
Uma solicitação completa e independente não requer que o servidor, enquanto processa a solicitação, tenha de armazenar nenhum tipo de contexto ou sessão. Um cliente REST deve incluir dentro do cabeçalho e corpo HTTP todos os parâmetros, contexto e dados necessários para que o servidor gere a resposta. Isto aumenta o desempenho do serviço REST e simplifica o design e implementação do servidor, já que a ausência de sessões de clientes elimina a necessidade de sincronizar dados de sessão com aplicações externas.

Informação cacheable
Para melhorar a eficiência no tráfego de rede, as respostas do servidor devem ter a possibilidade de serem marcadas como cacheáveis. Esta informação é utilizada pelos clientes REST para decidir se fazem uma cópia local do recurso com a data e hora da última alteração de estado do recurso. Em tal caso, o cliente realiza solicitações do estado do recurso de forma que, se o estado não tiver mudado, o servidor apenas lhe responde com uma mensagem muito pequena indicando que não mudou. Isto permite otimizar o tráfego de rede.

Interface uniforme
Uma das características principais dos serviços Web REST é o uso explícito de métodos HTTP (HyperText Transfer Protocol). Estes métodos são indicados no cabeçalho HTTP por parte do cliente e são os seguintes:
• GET: recolhe informação de um recurso
• PUT: modifica ou atualiza o estado de um recurso
• POST: cria um novo recurso no servidor
• DELETE: elimina um recurso do servidor.
Habitualmente, um URL numa solicitação HTTP GET identifica um recurso. Por exemplo, na seguinte solicitação estaria a ser solicitado o estado de um recurso chamado “SensorHumedad_001” dentro do catálogo de sensores da MiEmpresa:
http://www.MiEmpresa.com/Sensores/SensorHumedad_001

Outra maneira de solicitar informação a um servidor é construindo um URL que inclua parâmetros que definam os critérios de pesquisa no servidor para que possa encontrar os recursos solicitados:
http://www.MiEmpresa.com/Sensores?Tipo=humedad&id=001

Um recurso é um URL lógico, não físico. Deste modo, não é necessário que no servidor exista uma página HTML para cada um dos sensores. Com um método POST seria gerado o novo recurso no servidor, o qual seria acessível como URL lógica.

O modo como o servidor gere as solicitações dos clientes deve estar oculto para estes. Um cliente não deve saber a linguagem de programação utilizada no servidor nem como este está a gerar a informação; simplesmente deve saber o modo de aceder à informação. Isto permite migrar de um servidor para outro, de uma linguagem para outra sem necessidade de fazer alterações nos clientes existentes.

Nos princípios definidos por REST diferencia-se o método GET dos demais, já que este não deve ter efeitos de alteração na informação contida no servidor. Os métodos PUT, POST e DELETE modificam um recurso, mas o GET só deve recolher informação, nunca modificar o recurso.

Acesso a recursos por nome
Um sistema REST é composto por recursos que são acedidos mediante URL, e estas devem ser intuitivas, previsíveis e fáceis de entender e compor. Uma maneira de consegui-lo é mediante uma estrutura hierárquica, similar a diretórios. Pode existir um nó raiz único, a partir do qual se criam os subdiretórios que exponham as áreas principais dos serviços, até formar uma árvore com a informação dos recursos.
O acesso aos recursos realiza-se como composição de um URL que identifique o recurso, e deve ser a mesma ainda que a implementação no servidor se modifique. O URL composto não deve conter chamadas a funções que executem código no servidor, pelo que não deveriam ser endereços de arquivos que executem ações (páginas com extensão .jsp, .php, .asp).

Recursos relacionados
Os recursos acessíveis no servidor costumam estar relacionados uns com os outros. Portanto, a informação de estado de um recurso deveria permitir aceder a outros recursos. Isto consegue-se adicionando no estado dos recursos links ou URL de outros recursos. Por exemplo, poder-se-ia pedir um recurso cujo estado identifique os sensores de um determinado tipo:
http://www.MiEmpresa.com/Sensores?Tipo=humedad
O servidor poderia devolver a listagem de todos os sensores desse tipo, e dentro da informação do estado pode-se incluir um link a cada um dos sensores, adicionando uma capacidade de Drill-down para aceder ao máximo detalhe. A resposta do servidor à solicitação anterior poderia ser similar a esta:
{Id}SensorHumedad_001 {Detalle}http://www.MiEmpresa.com/Sensores/SensorHumedad_001
{Id}SensorHumedad_002 {Detalle}http://www.MiEmpresa.com/Sensores/SensorHumedad_002
{Id}SensorHumedad_003 {Detalle}http://www.MiEmpresa.com/Sensores/SensorHumedad_003
{Id}SensorHumedad_004 {Detalle}http://www.MiEmpresa.com/Sensores/SensorHumedad_004

Uma boa prática nos serviços REST é não mostrar toda a informação do estado de um recurso numa solicitação, mas sim mostrar a informação de maneira gradual. Isto permite minimizar o uso da rede se o cliente não necessitar de muitos detalhes de um determinado recurso. Isto pode-se conseguir incluindo links no estado do recurso, sendo estes links outros recursos com maior nível de detalhe.

Resposta num formato conhecido
A representação de um recurso reflete o estado atual do mesmo e os seus atributos no instante em que o cliente realizou a solicitação. Este resultado pode representar simplesmente o valor de uma variável num instante de tempo, um registo de uma Base de Dados ou qualquer outro tipo de informação. Em qualquer dos casos, a informação deve ser entregue ao cliente num formato compreensível para ambas as partes e contida dentro do corpo HTTP. Este conteúdo deve ser simples e compressível por um humano e, claro, interpretável por uma aplicação. Isto permite utilizar o serviço REST por diferentes clientes independentemente da linguagem com que se tenham programado.

Os formatos mais habituais são JSON (JavaScript Object Notation) e XML (Extensible Markup Language), ainda que se aceitem outros, como CSV (Comma Separated Values). Cada formato tem as suas vantagens e desvantagens. Dado que JSON foi desenhado para JavaScript, a sua interpretação é muito direta neste ambiente. XML é fácil de expandir e contrair, já que a informação está aninhada; além disso, é um formato muito conhecido. CSV, por sua vez, é um formato compacto.

Nos serviços REST, dado que podem existir diferentes tipos de clientes, não se aconselha implementar um servidor que devolva o estado de um recurso num só formato. Isto pode-se conseguir de diferentes maneiras, como por exemplo, criar no servidor um URL diferente para cada formato, ou escrevendo um parâmetro no mesmo URL que o servidor interprete. A seguir, mostram-se ambas as opções:
http://www.MiEmpresa.com/Sensores/xml/Sensor001
http://www.MiEmpresa.com/Sensores/Sensor001?Output=xml