Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Neste artigo, falaremos muito sobre dois termos: REST e RESTful. Podemos definir REST (REpresentational State Transfer) como um estilo de arquitetura para sistemas hipermídia distribuídos – sistemas que lidam de maneira simultânea com textos, imagens, vídeos, etc. Por sua vez, o termo RESTful se refere aos sistemas que seguem os princípios REST.

Atualmente, empresas como Yahoo, Amazon, entre outras, estão utilizando amplamente esta tecnologia, o que a tornou popular. Um dos motivos disso deve-se ao fato de que se consegue facilmente fazer um cliente que utilize serviços da Amazon, ou mesmo acessar sua conta do twitter via um aplicativo simples. Tutoriais sobre isso são fáceis de achar, pois assim como consumi-los é trivial, a construção também é. Por isso, focaremos nas boas práticas na implementação desses serviços.

Neste artigo, conceituaremos os princípios REST, falaremos sobre os métodos e códigos de status HTTP, cache, cookies, segurança e testes. Para os exemplos de código, vamos utilizar o Jersey, que é a implementação de referência da especificação JAX-RS (API Java para web services RESTful).

A partir de agora, vamos analisar 10 boas práticas que tornarão seus serviços mais padronizados, seguros e melhores. Note que, o mais importante não é decorar, mas ter uma visão geral e se lembrar, principalmente, do que não fazer.

1. Entenda REST

A primeira boa prática não poderia ser outra senão entender o assunto que se está tratando. Assim, é muito importante conhecermos os princípios REST, para ter uma visão geral da arquitetura.

Um protocolo cliente/servidor sem estado

Nem o cliente e nem o servidor têm a necessidade de armazenar estados transitórios entre as mensagens de pedido e resposta. Esta restrição isola o cliente das alterações no servidor, uma vez que, entre duas requisições, não há ligação cliente-servidor. O cliente poderia receber algumas informações do servidor, e enquanto o primeiro fazia algum processamento, o segundo poderia ser até reiniciado, sem que o cliente perceba nada. De fato, a separação cliente/servidor deve ser bem clara: um módulo presta o serviço e o outro o consome.

Além disto, concorrência, segurança, escalabilidade e muitos conceitos de programação se tornam mais simples quando não há estados, e as aplicações tornam-se muito mais fáceis de desenvolver.

Um conjunto de operações bem definidas

REST se utiliza do conjunto de operações definidas no protocolo HTTP, em que as mais conhecidas são POST e GET. Adicionando o PUT e o DELETE, já temos um CRUD. Existem também mais alguns métodos como HEAD e OPTIONS, que veremos mais adiante.

Recursos

Recursos são os elementos de informação em uma arquitetura REST. Qualquer informação que puder ser nomeada pode ser considerada um recurso. Exemplos: usuários, produtos, documentos, imagens, outros recursos, etc. Cada recurso possui um conjunto de operações, conforme descrito no subtópico anterior.

Lembre-se que os recursos são coisas e não ações, por isso os nomes utilizados na URI devem ser padronizados como substantivos. Por exemplo, para um recurso usuário, faça com que o método da sua classe Java anotado com @GET seja executado caso seja feita uma solicitação GET à URI /user/. Como há uma padronização neste sentido, é um anti-padrão mapear a URI como /user/getUser/, pois as operações básicas – adicionar, recuperar, atualizar e remover – serão definidas pelos métodos HTTP.

2. REST não é para tudo

Além do REST, é possível construir web services usando SOAP. Veremos a seguir algumas situações onde cada estilo é mais recomendado. REST é interessante nas seguintes situações:

Por outro lado, use SOAP quando: