Diga não aos web services

1.979 visualizações

Publicada em

Apresentação sobre os problemas e falácias comuns pra quem vai usar web services baseados em SOAP.

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.979
No SlideShare
0
A partir de incorporações
0
Número de incorporações
16
Ações
Compartilhamentos
0
Downloads
23
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Diga não aos web services

  1. 1. Diga não aos web services Maurício Linhares – mauricio.linhares@gmail.com
  2. 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. 3. Você usa… Sabã… ops, SOAP! Eu resolvo o seu problema! Sou o protocolo padrão de mensagens dos web services!
  4. 4. Pelo menos ele não usa a cueca por cima da roupa… E como é que isso resolve o meu problema?
  5. 5. Os super-amigos se juntam para resolver o problema! WSDL – UDDI – HTTP – SMTP – FTP
  6. 6. Tá começando a chatear… E como é que eu uso esse monte de coisa?
  7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. E agora? O que é que eu vou usar?
  17. 17. REST A nova bala de prata
  18. 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. 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. 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. 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. 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. 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. 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. 25. Quem usa REST?  A internet toda, qualquer aplicação web pode ser vista, de certa forma, como uma aplicação REST;
  26. 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. 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;
  28. 28. 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.

×