REST Anti-Patterns

Comecei a estudar REST (REpresentational State Transfer) a algum tempo atrás, quando fazia testes com Adobe Flex usando HTTP-Service e backend Java com Servlets, solução caseira, antes de ser padronizado como uma JSR: JSR 311: JAX-RS: The Java API for RESTful Web Services (http://jcp.org/en/jsr/detail?id=311)

Com meu ingresso na Voiza e popularização do REST comecei a estudar melhor os conceitos e formas de aplicação desta estratégia, usada para desenhar e implementar aplicações com baixo acoplamento e que facilitem o intercâmbio de informações com outras aplicações.

Os protocolos utilizados, do nível mais baixo ao mais alto, não são o que definem se a aplicação é REST, mas comumente vemos a estratégia sendo implementada sobre o protocolo HTTP e, claro, sendo transportado pela pilha TCP/IP. Assim sendo, a implementação de REST sobre HTTP (HTTP RESTful) deve seguir a especificação do protocolo, usar os métodos HTTP (OPTIONS, GET, POST, DELETE, PUT, etc), mime-type adequado, cache, ser stateless, etc. Para quem no conhece o protocolo e deseja implementar alguma aplicação web-based, sugiro a leitura da RFC 2616: http://www.ietf.org/rfc/rfc2616.txt

Depois de ler a respeito, ver estratégias de implementação, testar algumas estratégias home made, ler a especificação na JSR e conversar com alguns colegas de trabalho -como o "bergamota" que usou Ruby On Rails (que é RESTful a partir da 2 versão)-, alguns pontos me deixaram com a "pulga atrás da orelha", Kent Beck diria que detectei mau cheiro (http://en.wikipedia.org/wiki/Code_smell), por que parece muito complicado implementar o REST seguindo tudo a risca.

Então comecei a procurar as boas práticas REST, como patterns, soluções de problemas conhecidos, etc, e também as más práticas, anti-patterns, estratgias de desenho e implementao a evitar, e foi assim que encontrei este excelente artigo do Stefan Tilkov, j meio antigo (2008), que fala de Anti-Patterns REST, ou seja, o que evitar, no fazer, na hora de desenhar e implementar aplicaes REST com HTTP, chamado pelo autor de RESTful HTTP.

Os 8 tópicos seguem abaixo (traduções melhores são bem-vindas):

1. Tunneling everything through GET (empacotar todas as chamadas através do método GET)
2. Tunneling everything through POST (empacotar todas as chamadas através do método POST)
3. Ignoring caching (ignorar o caching)
4. Ignoring response codes (ignorar os códigos de resposta HTTP -ver RFC-)
5. Misusing cookies (usar inadequadamente os cookies)
6. Forgetting hypermedia (esquecer a hipermídia)
7. Ignoring MIME types (ignorar os tipos MIME)
8. Breaking self-descriptiveness (quebrar a auto-descritividade)

O artigo na íntegra, com o uso correto e soluções recomendadas para cada tópico, pode ser lido aqui:
http://www.infoq.com/articles/rest-anti-patterns

Para entender melhor REST sugiro este artigo, tambm na infoQ:
http://www.infoq.com/articles/rest-introduction

Particularmente, concordo com os pontos colocados no artigo, e penso que serve de bom norteador para alguém que, como eu, é iniciante em REST.

Se interessar, aqui tem um apresentação falando sobre uma implementação real: http://www.infoq.com/presentations/REST-Financial-Service-Phillip-Ghadir onde o projeto começou com SOAP/WSDL/WS-* e mais tarde migrado para REST/APP usando o Atom Publish Protocol (APP) para expor os serviços (isto antes de inventarem o WADL anlogo ao WSDL). Foi o melhor exemplo de algo prático que encontrei.