Não faz muito tempo, quando sistemas precisavam trocar informações entre sí, profissionais da área de TI iniciavam um doloroso processo para exportação e importação das informações. Algumas atividades desenvolvidas neste processo eram: geração de planilhas, documentos de texto, tabelas, etc. Além das dificuldades imagináveis neste processo, existia ainda a barreira do tempo, isto é, nada era feito na hora. Entre a solicitação e a entrega das informações, existia umgap considerável (de dias e, dependendo da quantidade e do tipo de informações solicitadas, até meses).

Visando solucionar este problema, pesquisas foram instensificadas para propor novas metodologias para conectar diferentes sistemas através da internet (a maior e mais complexa das redes) e, surgiram então os WebServices. Existem diversas formas disponíveis para implementação deWebServices. Várias metodologias associadas foram propostas para realização desta operação, dentre as quais podemos citar: CORBA, RPC, WSDL, UDDI, SOAP, REST, dentre outros.

Este post se concentrará na apresentação dos principais conceitos que justificam a existência do modelo REST.

Neste ponto você pode estar se perguntando: Porque REST e não SOAP ou outro modelo? REST é melhor? Note, nossa intenção com este post não é discorrer sobre qual dos modelos de implementação de WebServices é melhor ou pior ou ainda, tentar extrair qualquer resultado de testes comparativos. Nossa ideia com este texto é simplesmente apresentar o modelo REST, por dois motivos principais: é uma metodologia que estou utilizando em um projeto atual da empresa e, além disso, os próximos posts desse site utilizarão o modelo REST para efetuar a comunicação nos exemplos apresentados. Poderíamos justificar ainda o fato de REST ser um modelo de arquitetura mais simples que seus concorrentes, mas esta é uma afirmação que costumeiramente está presa a contextos, portanto, não cabe aqui.

REST – O que é?

REST é o acrônimo para Representational State Transfer (em português, Estado Representacional de Transferência). O termo REST foi utilizado pela primeira vez na tese de doutorado do, hoje doutor, Dr. Roy Fielding, criador do protocolo HTTP. Em sua tese, Fielding apresenta a web como um ambiente de estado representacional de transferências, assim, REST não é de forma alguma um padrão arquitetural mas sim, um estilo para fazer as coisas.

O modelo REST é dito mais simples que os demais, como SOAP, por exemplo, por trabalhar de forma cooperativa com o protocolo HTTP com a possibilidade de “cacheamento” dos dados e, serviços que utilizam este modelo de arquitetura, são conhecidos como RESTful. Neste modelo, qualquer coisa que possa ser caracterizada como algo “utilizável” por um sistema, pode ser referenciada, desde objetos concretos até objetos abstratos, como “conta bancária”, por exemplo. Assim, basta expor estes elementos através da URI (Uniform Resource Indicator) para que outro sistema possa se conectar e obter as informações passadas.

REST – Como funciona?

 

Um princípio fundamental de WebServices é: deve ser uma interface pública, isto é, acessível a qualquer pessoa que desejar acessá-lo. Evidentemente que, para que este acesso seja realizado, um padrão de comunicação deve ser adotado. No caso do modelo REST, estamos falando do padrãoHTTP, protocolo padrão da web. Outros modelos arquiteturais (como SOAP, por exemplo), utilizam outros protocolos como padrão.

 

Como mencionado anteriormente, os recursos de um serviço devem ser disponibilizados de forma que possam ser acessíveis através de uma URI padrão, já que este é o padrão de interconexão daweb.

Em relação ao procedimento de chamada ao serviço, é importante lembrar que, como estaremos utilizando o padrão HTTP para comunicação, por inércia estamos falando dos mesmos verbos associados, isto é, GET, POST, PUT e DELETE (existem outros, mas basicamente estes), assim, o verbo utilizado na requisição, indica ao serviço que ação este deve tomar. A Figura 1 apresenta um resumo das ações impostas pelos verbos.

Figura 1: Resumo das ações dos verbos HTTP (fonte: http://msdn.microsoft.com/pt-br/library/dd941696.aspx)

Outra característica importante em relação ao modelo REST é que, justamente pelo fato de ele não ser uma especificação padrão, não temos um padrão para sua representação, assim, podemos representar os dados da forma que acharmos mais conveniente para a situação problema em questão. É perfeitamente possível, por exemplo, representarmos os dados a serem trafegados, em formato XML, em formato JSON, RSS, entre outros (para mim, este é um fator importante para adoção do modelo REST).

Entendendo o esquema de URI’s

Para que você possa começar a vislumbrar como se comportam as URI’s no modelo REST, imagine um cenário de clínica médica. Uma web application foi construída de modo a gerenciar todas as ocorrências da clínica, tais como: pacientes, consultas, médicos, especialidades, exames, agendamentos, planos de saúde, etc. Imagine ainda que um sistema parceiro, digamos de um hospital, queira saber todas as informações relacionadas ao paciente 1240 da clínica. Considerando “minhaclinica.com.br” como URI base para o sistema da clínica, o sistema cliente poderia fazer a requisição da seguinte forma:

Note, neste caso, estamos solicitando via GET ao serviço, que nos retorne os dados do paciente cujo código é 1240. Neste caso, o serviço devolveria o resultado de acordo com o padrão especificado (um XML, por exemplo). A Figura 2 ilustra este processo.

Figura 2: O modelo de solicitação via REST

Bom pessoal, por hoje é isso. Espero que este texto possa tê-lo ajudado a compreender de forma mais clara como funciona o modelo REST de comunicação. No próximo post apresentarei como é possível enviar uma solicitação a um serviço REST qualquer, obter o resultado e armazená-lo no banco de dados.