Existem muitas definições para o termo Serviços Web. Para motivar nossa discussão, vamos nos basear inicialmente na definição publicada pelo W3C, como segue: “Um serviço web é um sistema de software projetado para suportar a interação entre máquinas de forma interoperável em uma rede de computadores. Este serviço possui uma interface descrita em um formato processável por máquina (especificamente o WSDL). Outros sistemas interagem com o serviço web de acordo com esta interface, utilizando mensagens SOAP, tipicamente enviadas via HTTP com uma serialização em XML”.
Tal definição é perfeitamente realizável e amplamente adotada. Grandes empresas como Microsoft e IBM participaram ativamente do desenvolvimento desta abordagem através do lançamento de produtos e publicação de artigos. O problema existente nesta definição é que ela trata de um grupo específico de tecnologias, mais precisamente o protocolo SOAP e as linguagens WSDL e XML.
Segundo Leonard Richardson e Sam Ruby em seu livro “RESTful Web Services”, existem na verdade três grupos de serviços web, distintos em termos de arquitetura e tecnologias adotadas. São eles: Serviços RESTful, Serviços RPC, e Serviços REST-RPC. Cada grupo deve responder duas questões relativas à sua arquitetura:
- Qual a ação a ser executada?
- Qual o escopo de execução desta ação?
Serviços RESTful são os mais fiéis ao HTTP, pois utilizam todo o potencial oferecido por este protocolo. A ação a ser executada é definida pelo método HTTP (também conhecido como verbo HTTP). O protocolo oferece cinco métodos principais: GET, HEAD, POST, PUT, e DELETE. Todos os métodos são aplicados em recursos, ou seja, nos objetos gerenciados pelo serviço. Por este motivo, uma arquitetura RESTful é dita orientada a recurso.
O método GET trata da recuperação real de recursos, ao passo que HEAD retorna apenas os cabeçalhos (ou meta-dados) que descrevem os recursos afetados pela requisição HTTP.
Já os métodos POST e PUT tratam da inserção e atualização de recursos. A especificação HTTP é um tanto abrangente na comparação entre estes dois métodos. Alguns serviços web utilizam PUT para inserção, enquanto outros utilizam POST. A discussão é polêmica realmente. Após rever a especificação oficial, entendo que POST deve ser utilizado para a inserção de recursos aninhados. De acordo com esta interpretação, o método PUT seria usado tanto para a inserção, quanto para a atualização de recursos completos/independentes. Independentemente da sua interpretação, seja coerente na utilização destes métodos quando for criar seus próprios serviços, e documente suas decisões. Caso você esteja apenas consumindo serviços já disponíveis na Internet, tenha o cuidado de verificar qual a interpretação do provedor deste serviço.
Por fim, o método DELETE deve ser enviado para a remoção do recurso. Alguns serviços preferem executar uma técnica conhecida como soft-delete, onde o recurso não é efetivamente removido da base, mas apenas inativado. Outros preferem executar o hard-delete, o que faz com que o recurso nunca mais possa ser acessado, pois já não existe na base. Novamente, a especificação do serviço deve cobrir esta decisão.
Agora, sobre a definição do escopo de execução do método, o paradigma RESTful defende a utilização da URI presente na requisição HTTP para este fim. Nesta abordagem, a URI contém não apenas o caminho do serviço em questão, mas também qualquer parâmetro necessário para identificação única do recurso a ser afetado.
Observe o primeiro exemplo a seguir, onde uma aplicação cliente envia uma mensagem HTTP utilizando o método GET, e uma URI que identifica a foto de número 123. Neste cenário fictício, gallery.com seria uma aplicação de gerenciamento de fotos, que oferece uma API pública de acordo com os princípios RESTful. Neste momento, a aplicação quer recuperar/obter a foto armazenada em gallery.com.
GET /photo/123 HTTP /1.1
Host: gallery.com
No segundo exemplo, a requisição HTTP enviada utiliza o método DELETE, o que significa que a foto 123 será removida da base em gallery.com.
DELETE /photo/123 HTTP /1.1
Host: gallery.com
Note que apenas o método HTTP foi alterado, enquanto que a URI permaneceu intacta. Esta é uma característica marcante dos serviços RESTful. Aquela URI sempre identifica o mesmo recurso, ou seja, a foto 123. Este é o escopo de execução. Já o método HTTP apenas diz qual a ação a ser executada (recuperação no primeiro exemplo, e deleção no segundo).
Portanto, podemos perceber que é tranquilamente possível a criação de serviços web sem a utilização do SOAP, protocolo utilizado na definição publicada pelo W3C. Na realidade, diversas empresas emergentes já oferecem interfaces RESTful para que outras empresas/aplicações possam se conectar a elas.
Como visto neste post, o paradigma RESTful utiliza apenas o HTTP, protocolo padrão da Web, e sem o qual a Web não existiria como a conhecemos hoje. Na prática, os desenvolvedores rapidamente percebem que o protocolo REST é mais leve e portável que o SOAP.
Nos próximos posts, pretendo tratar das outras duas arquiteturas para serviços web: Serviços RPC (SOAP como principal exemplo) e Serviços REST-RPC. Até lá!
Postagens
