Em poucas palavras do que li sobre o assunto, REST é um paradigma arquitetônico e o RESTful é um serviço web que usufrui deste paradigma. Pode ser conceituado também como um conjunto de restrições que define um padrão arquitetural com características específicas: entendo que benefícios e dificuldades aparecerão ao implementar um sistema seguindo o padrão REST.

Já de acordo com o Wikipedia, temos a definição de REST como Transferência de Estado Representativo (Representational State Transfer), sendo uma técnica de engenharia de software para sistemas hipermídia distribuídos como a World Wide Web. O termo se originou no ano de 2000, em uma tese de doutorado (PHD) sobre a web escrita por Roy Fielding, um dos principais autores da especificação do protocolo HTTP que é utilizado por sites da internet.

Li um post de Arnon sobre o assunto e ele versa sobre desvantagens e vantagens do REST. As três maiores vantagens de usar REST são (segundo Arnon):

Relativa facilidade de integração:

…uma boa API RESTful é encontrável a partir de sua URI inicial. Isso não quer dizer que qualquer aplicação chamando seu serviço vai automagicamente saber o que fazer. Significa, no entanto, que o desenvolvedor lendo sua API tentando integrá-la terá mais facilidade. Especialmente se a hipermidia te dá um mapa do que fazer a seguir

Uso de padrões difundidos – HTTP é a implementação mais comum de REST:

Falando HTTP que é o protocolo da web, emitir JSON ou ATOMPub significa que é muito mais fácil achar uma biblioteca que pode conectar em você em qualquer linguagem ou plataforma.

Escalabilidade:

…comunicação sem estados, repositórios replicados constituem um bom potencial de escalabilidade.

Arnon Rotem-Gal-Oz também discute algumas das desvantagens do REST. Na sua visão as duas maiores desvantagens do REST são:

Implementações “Lo-rest” (usar apenas GET e POST), que são específicas de REST sobre HTTP:

Enquanto tecnicamente pode ainda ser RESTful, para mim uma interface uniforme com 2 verbos é muito pequena para ser realmente útil (o que na verdade faz muito da implementação unRESTful)

Finalmente, Arnon aponta os casos feios de REST, que, na sua maioria, acontecem por causa do mau uso do REST:

Seguidores zelosos (termo usado por Arnon – prova novamente que discussões sobre REST são normalmente religiosas):

Não é algo único ao REST, toda boa tecnologia/ideia (Agile, TDD, etc.) tem sua parcela de seguidores que pensam que [insira sua tecnologia/ideia favorita] é a melhor coisa desde o pão fatiado e que todos deveriam fazer como eles fazem.

Não entendimento do REST:

… construindo uma implementação que é GETsful (ou seja, faz tudo com http GET) ou fazendo RPC puro onde a URI é o comando, fazendo CRUD com verbos HTTP, etc.

Arnon conclui seu post dizendo que:

REST parece simples, mas não é – ele requer pensar mais (por exemplo, identificar recursos, externalizar as transições de estado, etc.). … fazendo certo pode ser uma ferramenta importante e útil na sua caixa de ferramentas, [mas] … como qualquer arquitetura/tecnologia – uma implementação ruim pode NEGAR todos os benefícios.

Agora retomando o meu artigo após as citações de Arnon, trazendo este paradigma arquitetônico ao meu dia-a-dia como Gestor de Projetos, devo dizer que REST é um estilo de se projetar aplicativos da Web fracamente acoplados que contam com recursos nomeados — em forma de Localizador Uniforme de Recursos (URL), Identificador Uniforme de Recursos (URI) e Nome de Recurso Uniforme (URN), por exemplo — e não com mensagens. Engenhosamente, o REST transporta a infraestrutura já validada e bem-sucedida da Web — HTTP. Ou seja, o REST alavanca aspectos do protocolo HTTP como pedidos GET e POST. Esses pedidos são perfeitamente mapeados para necessidades de aplicativo de negócios padrão, como create read, update, and delete (CRUD).

Tabela 1. Mapeamento CRUD/HTTP

Tarefa do aplicativo Comando HTTP
Create POST
Read GET
Update PUT
Delete DELETE

Ao associar pedidos, que agem como verbos, com recursos, que agem como nomes, você termina com uma expressão lógica de comportamento — GET este documento e DELETE aquele registro, por exemplo.

Roy Fielding, o verdadeiro pai do REST, afirma em sua dissertação de PhD que o REST “enfatiza a escalabilidade das interações do componente, a generalidade das interfaces, a implementação independente de componentes e componentes intermediários para reduzir a latência da interação, forçar a segurança e encapsular sistemas legados”. Achei muito interessante a parte em que ele fala sobre redução de latência da interação, ou seja, quando estamos tratando de REDE/TCP/IP, a redução de latência ocorre quando temos uma eliminação de um ruído ou cascateamento, ou seja, no mundo da programação, o REST elimina algum interpretador para que a latência da interação seja reduzida.

Vamos aprender neste módico post também sobre o triângulo do REST, acredito que ele seja importante para que, ao menos conceitualmente, tenhamos uma visão melhor sobre requisição web.

Substantivos: Recursos

Substantivos são os nomes dos recursos do seu sistema. Quando fazemos requisições Web, precisamos falar o caminho da mesma, a URI (Unified Resource Identifier), ou seja, o identificador único de um recurso.

Então ao criar as URIs do nosso sistema devemos levar em conta que elas representam recursos, não ações. Em sistemas REST, nossas URIs devem conter apenas substantivos, que são nossos recursos: /produtos/edita não é boa, pois contém um verbo e não está identificando um recurso, mas sim uma operação. Para representar a edição de um produtos podemos usar a URI /produtos com o método HTTP PUT.

Verbos: Operações

Uma das característas mais importantes de REST é que você tenha um conjunto pequeno e fixo de operações bem definidas, gerando uma interface uniforme. Desse modo, para duas aplicações conversarem, elas não precisam implementar diversas operações: basta usar as operações definidas. Perceba que adicionar um produto e adicionar um usuário no sistema são operações equivalentes.

O protocolo HTTP possui sete operações — os métodos GET, POST, PUT, DELETE, HEAD, OPTIONS e TRACE. Duas delas (GET e POST) já são bem conhecidas e utilizadas: GET quando clicamos em links ou digitamos o endereço no navegador, e POST quando preenchemos formulários de cadastro. Cada método tem uma semântica diferente e juntando o método à URI, deveríamos conseguir representar todas as ações do nosso sistema. As semânticas principais são:

GET – recupera informações sobre o recurso identificado pela URI. Ex: listar produtos, visualizar o produto 45. Uma requisição GET não deve modificar nenhum recurso do seu sistema, ou seja, não deve ter nenhum efeito colateral, você apenas recupera informações do sistema.
POST – adiciona informações usando o recurso da URI passada. Ex: adicionar um produto. Pode adicionar informações a um recurso ou criar um novo recurso.
PUT – adiciona (ou modifica) um recurso na URI passada. Ex: atualizar um produto. A diferença fundamental entre um PUT e um POST é que no POST a URI significa o lugar que vai tratar a informação, e no PUT significa o lugar em que a informação será armazenada.
DELETE – remove o recurso representado pela URI passada. Ex: remover um produto.
HEAD, OPTIONS e TRACE – recuperam metadados da URI passada. Respectivamente o Header, quais métodos são possíveis e informações de debug.

Content Type: Representação

Quando fazemos uma aplicação não trafegamos um recurso pela rede, apenas uma representação dele. Por exemplo, quando queremos adicionar um produto ao sistema, passamos para o servidor uma representação do produto: dados do formulário. E quando pedimos uma lista de produtos para o servidor ele responde com uma representação HTML desses produtos. Mas não precisa ser restrito a isso: poderíamos adicionar um produto ao sistema via uma representação em XML, e o servidor poderia nos devolver uma lista de produtos em formato JSON.

Exemplo de um pedaço de código implementando o RESTful:

$curl = curl_init(); // Iniciando a sessão.
$aux_conect = "http://".$ip_v.":".$porta_v."/".$bde_v."/".$documento["_id"];

// Remove a chave _id do documento, necessário quando se vai adicionar mais um //atributo ao documento, caso isso não seja feito o banco retorna um erro de //conflito.

$documento["_id"] = false;
$documento = array_filter($documento);
curl_setopt($curl, CURLOPT_URL, $url);

//Define o tipo do conteúdo das mensagens a serem criadas, no caso text/json.

curl_setopt($curl, CURLOPT_HTTPHEADER, array("Content-Type: text/json"));
curl_setopt($curl, CURLOPT_CUSTOMREQUEST, "PUT");
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);

//Definindo a entrada dos dados ao documento.

curl_setopt($curl, CURLOPT_POSTFIELDS, json_encode($documento));
$retorno = curl_exec($curl);
curl_close($curl);
$retorno = json_decode($retorno);

//Quando um documento é criado com sucesso ele retorno a mensagem {ok ,true} //sendo assim faço a verificação abaixo

if(isset($retorno->ok) && $retorno->ok == "true") {

//retorna a mensagem.

}

Conclusão

Hoje eu passei 4 horas lendo diversos artigos sobre o assunto e posso dizer que o que foi descrito neste post não é nem 1% do que se deve falar deste assunto. ATÉ O PRÓXIMO POST!

[toggle title=”Referências” state=”open” ]http://pt.wikipedia.org/wiki/REST http://www.ibm.com/developerworks/br/library/j-rest/section3.html http://www.ibm.com/developerworks/br/library/os-understand-rest-ruby/ http://www.caelum.com.br/apostila-vraptor-hibernate/rest/#11-1-o-que-e-rest http://www.infoq.com/br/news/2009/05/Rest http://www.rgoarchitects.com/nblog/2008/08/21/UsingRESTAlongOtherArchitectureStyles.aspx https://groups.google.com/forum/#!topic/rails-br/Hdv4jA5TNmw[/toggle]

Author

Rodrigo Calado é sócio-fundador e CTO do Gran Cursos Online. Graduado em Gestão da Tecnologia da Informação, pós-graduando em Governança de TI pela Universidade Católica de Brasília e cursou MBA em Gestão e Empreendedorismo pela FGV. Possui convicta paixão pela área de tecnologia, educação digital, concursos públicos e empreendedorismo.

9 Comments

  1. Paulo Leandro Reply

    Muito legal cara, eu não tenho conhecimento sobre REST então obtive uma luz com este seu post. Abraço.

  2. Cesar Eduardo Ribeiro Fernande Reply

    Fala Rodrigo, bacana o artigo. Depois dá uma ollhada na Goldark http://www.goldark.com.br
    Permite criar api’s rest sem programação, com servidor e tudo. Backend completo.

Reply To Anônimo Cancel Reply