REST significa Transferência de Estado Representacional.
REST é uma arquitetura baseada em padrões da web e usa protocolo HTTP para comunicação de dados. Ele gira em torno de recursos em que cada componente é um recurso e um recurso é acessado por uma interface comum usando métodos padrão HTTP. O REST foi introduzido pela primeira vez por Roy Fielding em 2000.
Na arquitetura REST, um servidor REST simplesmente fornece acesso aos recursos e o cliente REST acessa e apresenta os recursos. Aqui, cada recurso é identificado por URIs / IDs globais. REST usa várias representações para representar um recurso como texto, JSON e XML. Hoje em dia, JSON é o formato mais popular usado em serviços da web.
Os métodos HTTP mais conhecidos são comumente usados na arquitetura baseada em REST -
GET - Fornece acesso somente leitura a um recurso.
PUT - Usado para atualizar um recurso existente ou criar um novo recurso.
DELETE - Usado para remover um recurso.
POST - Usado para criar um novo recurso.
OPTIONS - Usado para obter as operações com suporte em um recurso.
Um serviço da web é uma coleção de protocolos e padrões abertos usados para trocar dados entre aplicativos ou sistemas. Os aplicativos de software escritos em várias linguagens de programação e em execução em várias plataformas podem usar serviços da web para trocar dados em redes de computadores como a Internet de maneira semelhante à comunicação entre processos em um único computador.
Os serviços da Web baseados na arquitetura REST são conhecidos como serviços da Web RESTful. Esses serviços da web usam métodos HTTP para implementar o conceito de arquitetura REST. Um serviço da web RESTful geralmente define um URI, Uniform Resource Identifier um serviço, fornece representação de recursos como JSON e um conjunto de métodos HTTP.
A arquitetura REST trata cada conteúdo como um recurso. Esses recursos podem ser arquivos de texto, páginas html, imagens, vídeos ou dados dinâmicos de negócios. O REST Server simplesmente fornece acesso aos recursos e o cliente REST acessa e modifica os recursos. Aqui, cada recurso é identificado por URIs / IDs globais.
REST usa várias representações para representar um recurso onde texto, JSON, XML. XML e JSON são as representações de recursos mais populares.
A seguir estão pontos importantes a serem considerados ao projetar um formato de representação de um recurso em um serviço da web RESTful -
Understandability - Tanto o servidor quanto o cliente devem ser capazes de entender e utilizar o formato de representação do recurso.
Completeness- O formato deve ser capaz de representar um recurso completamente. Por exemplo, um recurso pode conter outro recurso. O formato deve ser capaz de representar estruturas de recursos simples e complexas.
Linkablity - Um recurso pode ter uma ligação a outro recurso, um formato deve ser capaz de lidar com tais situações.
Os serviços da Web RESTful usam o protocolo HTTP como meio de comunicação entre o cliente e o servidor.
Um cliente envia uma mensagem na forma de uma solicitação HTTP e o servidor responde na forma de uma resposta HTTP. Esta técnica é denominada Messaging. Essas mensagens contêm dados e metadados da mensagem, ou seja, informações sobre a própria mensagem.
Uma solicitação HTTP tem cinco partes principais -
Verb - Indique métodos HTTP como GET, POST, DELETE, PUT etc.
URI - Uniform Resource Identifier (URI) para identificar o recurso no servidor.
HTTP Version - Indique a versão HTTP, por exemplo HTTP v1.1.
Request Header- Contém metadados para a mensagem de solicitação HTTP como pares chave-valor. Por exemplo, tipo de cliente (ou navegador), formato compatível com o cliente, formato do corpo da mensagem, configurações de cache etc.
Request Body - Conteúdo da mensagem ou representação de recursos.
Uma resposta HTTP tem quatro partes principais -
Status/Response Code- Indica o status do servidor para o recurso solicitado. Por exemplo, 404 significa recurso não encontrado e 200 significa que a resposta está ok.
HTTP Version - Indique a versão HTTP, por exemplo HTTP v1.1.
Response Header- Contém metadados para a mensagem de resposta HTTP como pares chave-valor. Por exemplo, comprimento do conteúdo, tipo de conteúdo, data de resposta, tipo de servidor etc.
Response Body - Conteúdo da mensagem de resposta ou representação de recursos.
O endereçamento refere-se à localização de um recurso ou vários recursos no servidor. É análogo localizar o endereço postal de uma pessoa.
URI significa Uniform Resource Identifier. Cada recurso na arquitetura REST é identificado por seu URI.
O objetivo de um URI é localizar um ou mais recursos no servidor que hospeda o serviço da web.
Um URI tem o seguinte formato -
<protocol>://<service-name>/<ResourceType>/<ResourceID>VERB identifica a operação a ser executada no recurso.
A seguir estão os pontos importantes a serem considerados ao projetar um URI -
Use Plural Noun- Use o substantivo plural para definir recursos. Por exemplo, usamos usuários para identificar usuários como um recurso.
Avoid using spaces - Use sublinhado (_) ou hífen (-) ao usar um nome de recurso longo, por exemplo, use authorized_users em vez de% 20users autorizados.
Use lowercase letters - Embora o URI não faça distinção entre maiúsculas e minúsculas, é uma boa prática manter o url apenas em letras minúsculas.
Maintain Backward Compatibility- Como o Web Service é um serviço público, um URI, uma vez tornado público, deve estar sempre disponível. Caso o URI seja atualizado, redirecione o URI mais antigo para o novo URI usando o código de status HTTP, 300.
Use HTTP Verb- Sempre use o verbo HTTP como GET, PUT e DELETE para fazer as operações no recurso. Não é bom usar nomes de operações em URI.
De acordo com a arquitetura REST, um serviço da Web RESTful não deve manter um estado de cliente no servidor. Essa restrição é chamada de apatridia. É responsabilidade do cliente passar seu contexto ao servidor e então o servidor pode armazenar esse contexto para processar a solicitação posterior do cliente. Por exemplo, a sessão mantida pelo servidor é identificada pelo identificador de sessão passado pelo cliente.
A seguir estão os benefícios da apatridia nos serviços da Web RESTful -
Os serviços da Web podem tratar cada solicitação de método independentemente.
Os serviços da Web não precisam manter as interações anteriores do cliente. Ele simplifica o design do aplicativo.
Como o próprio HTTP é um protocolo sem estado, os serviços da Web RESTful funcionam perfeitamente com o protocolo HTTP.
A seguir está a desvantagem da ausência de estado em serviços da Web RESTful -
Os serviços da Web precisam obter informações extras em cada solicitação e, em seguida, interpretar para obter o estado do cliente, caso as interações com o cliente precisem ser cuidadas.
Operações idempotentes significam que seu resultado sempre será o mesmo, não importa quantas vezes essas operações sejam chamadas.
As operações PUT e DELETE são idempotentes.
As operações GET são somente leitura e são seguras.
As operações PUT e POST são quase iguais, com a diferença apenas no resultado, onde a operação PUT é idempotente e a operação POST pode causar resultados diferentes.
Ele deve listar as operações com suporte em um serviço da web e deve ser somente leitura.
Ele deve retornar apenas o cabeçalho HTTP, sem corpo e deve ser somente leitura.
O armazenamento em cache refere-se ao armazenamento da resposta do servidor no próprio cliente, de modo que um cliente não precise fazer solicitações ao servidor para o mesmo recurso repetidamente. Uma resposta do servidor deve ter informações sobre como o armazenamento em cache deve ser feito para que um cliente armazene em cache a resposta por um período de tempo ou nunca armazene em cache a resposta do servidor.
O cabeçalho da data fornece a data e a hora do recurso quando ele foi criado.
O cabeçalho da última modificação fornece a data e a hora do recurso quando foi modificado pela última vez.
Cache-Control é o cabeçalho principal para controlar o cache.
O cabeçalho expira define a data de expiração e a hora do armazenamento em cache.
A diretiva pública indica que o recurso pode ser armazenado em cache por qualquer componente.
A diretiva privada indica que o recurso pode ser armazenado em cache apenas por cliente e servidor, nenhum intermediário pode armazenar o recurso em cache.
A diretiva no-cache / no-store indica que o recurso não pode ser armazenado em cache.
A diretiva max-age indica que o armazenamento em cache é válido até max-age em segundos. Depois disso, o cliente deve fazer outro pedido.
A diretiva must-revalidate fornece indicação ao servidor para revalidar o recurso se max-age tiver passado.
Sempre mantenha conteúdos estáticos como imagens, css, JavaScript armazenáveis em cache, com data de validade de 2 a 3 dias. Nunca mantenha a data de validade muito alta.
O conteúdo dinâmico deve ser armazenado em cache por apenas algumas horas.Como os serviços da web RESTful funcionam com caminhos de URLs HTTP, é muito importante proteger um serviço da web RESTful da mesma maneira que um site é protegido. A seguir estão as melhores práticas a serem seguidas ao projetar um serviço da web RESTful -
Validation- Valide todas as entradas no servidor. Proteja seu servidor contra ataques de injeção de SQL ou NoSQL.
Session based authentication - Use a autenticação baseada em sessão para autenticar um usuário sempre que uma solicitação for feita a um método de serviço da web.
No sensitive data in URL - Nunca use nome de usuário, senha ou token de sessão na URL, esses valores devem ser passados para o Web Service via método POST.
Restriction on Method execution- Permitir o uso restrito de métodos como GET, POST, DELETE. O método GET não deve ser capaz de excluir dados.
Validate Malformed XML/JSON - Verifique se há entrada bem formada passada para um método de serviço da web.
Throw generic Error Messages - Um método de serviço da web deve usar mensagens de erro HTTP como 403 para mostrar acesso proibido etc.
Os códigos de status HTTP são códigos padrão e referem-se ao status predefinido da tarefa realizada no servidor. Por exemplo, HTTP Status 404 afirma que o recurso solicitado não está presente no servidor.
Isso significa, OK, mostra sucesso.
Significa, CREATED, quando um recurso é criado com sucesso usando a solicitação POST ou PUT. Retorne o link para o recurso recém-criado usando o cabeçalho do local.
Significa SEM CONTEÚDO, quando o corpo da resposta está vazio, por exemplo, uma solicitação DELETE.
Significa NÃO MODIFICADO, usado para reduzir o uso da largura de banda da rede no caso de solicitações GET condicionais. O corpo da resposta deve estar vazio. Os cabeçalhos devem ter data, localização, etc.
Isso significa que BAD REQUEST, afirma que uma entrada inválida é fornecida, por exemplo, erro de validação, dados ausentes.
Significa, FORBIDDEN, afirma que o usuário não está tendo acesso ao método que está sendo usado, por exemplo, excluir o acesso sem direitos de administrador.
Isso significa que NÃO ENCONTRADO afirma que o método não está disponível.
Significa, CONFLICT, situação de conflito de estados durante a execução do método, por exemplo, adicionando entrada duplicada.
Isso significa que INTERNAL SERVER ERROR, afirma que o servidor lançou alguma exceção ao executar o método.
JAX-RS significa JAVA API para RESTful Web Services. JAX-RS é uma API e especificação de linguagem de programação baseada em JAVA para fornecer suporte para serviços da Web RESTful criados. Sua versão 2.0 foi lançada em 24 de maio de 2013. JAX-RS faz uso intenso de anotações disponíveis no Java SE 5 para simplificar o desenvolvimento da criação e implantação de serviços da Web baseados em JAVA. Ele também fornece suporte para a criação de clientes para serviços da Web RESTful.