O documento apresenta uma discussão sobre web services e REST. Ele começa apresentando o protocolo SOAP para web services e suas limitações. Em seguida, introduz o estilo arquitetural REST, baseado nos princípios da web e HTTP, que usa recursos acessíveis por URLs em diferentes representações. O documento argumenta que REST é mais limpo, independente de plataforma e integra melhor com clientes leves como navegadores.

1. Diga não aos web services
Maurício Linhares – mauricio.linhares@gmail.com

2. Baseado em fatos irreais…
Eu preciso fazer vendas
usando cartões de
crédito, mas como é que
o meu sistema fala com
as operadoras?

3. Você usa… Sabã… ops, SOAP!
Eu resolvo o seu
problema!
Sou o protocolo padrão
de mensagens dos web
services!

4. Pelo menos ele não usa a cueca
por cima da roupa…
E como é que isso
resolve o meu
problema?

5. Os super-amigos se juntam para
resolver o problema!
WSDL – UDDI – HTTP – SMTP – FTP

6. Tá começando a chatear…
E como é que eu
uso esse monte de
coisa?

7. Mais fácil do que fazer aposentado
tirar empréstimo!
Primeiro, você usa UDDI
para descobrir aonde
estão os serviços que
você está interessado
em consumir.

8. Mais fácil do que falar “Tacho sujo,
chuchu chocho”
Depois você vai consumir
os arquivos WSDL que
descrevem os serviços
com uma ferramenta
geradora de clientes de
web services.

9. Mais fácil que comprar com cartão
corporativo alheio
Aí você vai poder
finalmente enviar as
requisições dos seus
serviços via HTTP,
SMTP, FTP…

10. Que demais!
Então é só eu buscar
as operadoras de
cartão num registro
UDDI, ler os WSDLs
padrão e começar a
vender com cartão de
crédito usando
SMTP?

11. Errr… quase….
Ainda não existe nenhum
registro UDDI pras
operadoras de cartão de
crédito, os formatos das
mensagens que eles
usam não são iguais e
quase ninguém usa
serviços sem HTTP.

12. O mundo real é duro
 Registros UDDI são tão lendários que o
próximo “Jurassic Park” vai ter um;
 O único padrão das mensagens é como o
formato delas é definido (WSDL), quase
nenhuma industria de peso tem formatos
de mensagens padronizados;
 Ninguém usa web services em SOAP sem
HTTP;

13. Mas ainda fica pior
 As ferramentas que geram e consomem
WSDLs costumam não ser muito
amigáveis quando lidam com plataformas
diferentes;
 Java tem problemas sérios de
comunicação com serviços .Net;

14. Acabou?
 Até mesmo as diversas ferramentas de
geração/consumo de web services tem
incompatibilidades entre si;
 O modo de invocação dos web services
mata qualquer possibilidade de se
desenvolver clientes Ajax para eles;

15. Hum…
 A “independência” de protocolos de
transporte faz com que os web services
usem muito pouco (ou quase nada) das
capacidades do protocolo de transporte;
 Web services sobre HTTP ignoram
completamente as políticas de
idempotência e segurança do protocolo;

16. E agora?
O que é que eu vou
usar?

17. REST
A nova bala de prata

18. Representational State Transfer
 Baseado nos princípios da WWW e do procotolo
HTTP;
 É um estilo de arquitetura para sistemas
baseado nas experiências da internet;
 Apresentado ao mundo na tese de doutorado de
Roy Fielding em 2000;

19. Tudo são recursos acessíveis por
URLs
 http://loja.com/produtos/1
 http://blog.br/posts/meu-primeiro-post
 http://mapas.mundo/Brasil/Paraíba/João_
Pessoa

20. Dissecando os recursos
 Endereçabilidade e conexões – recursos
são acessíveis através de endereços e
apontam pra outros recursos (Google?);
 Inexistência de estado – requisisões que
operam em recursos devem conter toda a
informação necessária para executar a
operação;

21. Os recursos estão disponíveis em
diversas representações
 Qualquer formato que você achar
necessário, XHTML, JSON, XML, texto
puro;
 A escolha do formato do recurso é apenas
uma questão de disponibilidade do
servidor;

22. Falando em servidores…
 Completamente sem estado, assim como um
servidor HTTP;
 Todo estado do servidor deve ser mantido como
recursos, não como “cookies” ou “sessões”;
 Servidores são completamente independentes
dos clientes;

23. A interface comum
 Existe uma única interface para se
acessar os recursos e ela é igual para
todos;
 Se você conhece um, conhece todos;

24. E os clientes?
 Podem ser escritos em qualquer linguagem que
suporte o protocolo de comunicação;
 Nada de formatos exóticos baseados em XML;
 Não dependem de geradores de código ou de
ferramentas complexas de invocação de
serviços;
 Integração simplificada com clientes leves,
como navegadores usando Ajax;

25. Quem usa REST?
 A internet toda, qualquer aplicação web
pode ser vista, de certa forma, como uma
aplicação REST;

26. Falando sério…
 Google (removeu tudo que era SOAP);
 Yahoo;
 Amazon.com (mas usa SOAP também);
 Flickr;
 Blogs que usam Atom ou RSS (todos :P);

27. E agora José?
 Você não tem mais motivos pra acha que web
services são a única solução;
 Você sabe que REST é limpo, independente de
plataforma ou ferramentas e não tem um nome
de duplo sentido (será?);
 Você aprendeu que pode dizer a todo mundo
que usa REST desde sempre;

29. Referências
 http://en.wikipedia.org/wiki/Representation
al_State_Transfer
 Leonard Richardson & Sam Ruby. Restful
Web Services, O’Reilly;
 Steve Graham. Building Web Services
With Java, Developers Library.