Um modelo de arquitetura para sistemas web que me chamou muita atenção um ano atrás(tanto que fiz dois trabalhos para faculdade sobre, que infelizmente perdi) foi o REST, elaborado por, nada mais, nada menos, que Roy Thomas Fielding, que participa de muita coisa importante para a internet, essa arquitetura descreve simplesmente a web como ela é.
Consiste em utilizar de os recursos base da web(o HTTP) para construção de webservices, sem overhead e envelopes extras, tornando a interação(e o desenvolvimento) simples e não burocrática, explora os recursos já prontos, suficientes e comprovada eficiencia(afinal toda a web usa) do HTTP. Usa os conceitos que tornam a web o que ela é hoje.
Um serviço REST(ou RESTful) é definido por recursos, que possuem uma representação e um estado, estado esse que pode ser mudado(ou transferido) através de ligações(os links). Não é tão complexo como pode parecer:
Recursos é o item a ser tratado, são por exemplo usuários, produtos ou artigos. A Representação desse recurso é a pagina a ser apresentada, como o HTML ou o XML ou o JSON, essa representação contém o estado do recurso. O Estado são os dados do recurso(nome, preço, texto...), o cliente muda o estado na aplicação através de links, requisitando estados diferentes e trocando o recurso. Links são muito importante, tudo deve estar "hiperlinkado".
Comparado com Orientação a Objetos, o Recurso seria o Objeto, o Estado é o próprio estado do objeto(os atributos) mas os métodos nós vemos logo adiante. A representação é a apresentação desse objeto em um formato de mídia.
É assim que servimos páginas na web, uma página é um recurso demonstrando o estado da aplicação, e nós mudamos esse estado seguindo os links que nos são apresentados.
Mas e a implementação? Rest se baseia em duas tecnologias principalmente, são itens já muito bem testados e que usamos todo dia: URL (ou URI) e o HTTP.
Cada recurso possui um identificador, que é o seu endereço em um sistema. Cada recurso possui uma URI (Uniform Resource Identifier). Você requisita essa URI e lhe é devolvido o estado desse recurso.
O protocolo para RESTful webservices é o HTTP, dividamos ele em quatro partes:
- O Método da requisição (também chamado de verbo) define a ação que vamos tomar.(PUT, POST, DELETE, GET, OPTIONS, HEAD...).
- A URI da requisição define o recurso sobre o qual aplicar o método.
- E o Tipo (MIME/TYPE) define qual representação vamos renderizar e devolver. É o cabeçalho ACEPT-MIME em preferência a "extensão da URL".
- Com base nesses dados formatamos a Resposta e enviamos de volta ao consumidor.
Na prática funciona mais ou menos assim:
- Uma chamada HTTP "GET /user/login" exibe(get) os dados do usuário(recurso) no formato padrão, já que não especificado.
- O HTTP "GET /user/login/posts.json" retornaria os "posts"(subrecurso de usuário) no formato JSON.
- Já "POST /article" está inserindo um artigo, enquanto "POST /article/12" pode atualizar o artigo 12.(Poderia, ou até deveria, ser usado o PUT para atualizar, mas há controvérsias).
- A requisição "POST /article/12/comment" pode adicionar um comentário ao artigo 12.
- Seguindo assim, a ação de "DELETE /article/12/comment/2" exclui este comentário e "GET /article.xml" retorna a lista de artigos em XML.
- Pode até usar "GET /article/12.pdf" ou "PUT /user/diogo/picture.jpg".
O que é mais importante aqui é a conformidade do uso do HTTP. Um requisição do tipo GET deve apenas retornar dados, nunca alterar nada. Uma do tipo POST deve atualizar ou inserir um recurso, idem para o PUT. Recuperar dados nunca deve depender de POST, e um GET nunca deve alterar nada. Isso é importante para manter a consistência da aplicação, e podermos confiar nos métodos. Dois acessos seguidos de GET(ou HEAD ou OPTIONS) em um recurso deve ter o mesmo efeito que três ou nenhum, enquanto POST ou PUT podem fazer diferença.
REST trás, pelo HTTP, bons recursos prontos para serem usados:
- Cache eficiente, através dos Headers devidos do HTTP (expires...).
- Autênticação, BASIC ou DIGEST
- Segurança através de SSL (HTTPS)
- Falta de estado(confusão aqui, leia a seguir), por falta de necessidade.
REST é stateless, isso que dizer que ele não mantém o estado do cliente. Bom, nesse caso não é o mesmo estado que falei mais acima. O Estado do Recurso são seus atributos, e são mantidos no servidor(Banco de dados, Filesystem...) e o estado do cliente é o ponto em que a aplicação que consume o serviço esta(ou a seção).
Dessa forma o fluxo ou ordem da navegação do cliente não afeta qual recurso vai ser apresentado, e nem o cliente precisa manter informação sobre em que ponto parou para poder fazer uma requisição.
Um bom link é o REST: Paul James, muito conteúdo bom lá.
Como podem ver REST não é nada novo, já fazemos a web assim a muito tempo, mas agora temos uma forma mais elegante e um bom motivo para manter a simplicidade que faz da web o que ela é.
