diga não aos web services
TRANSCRIPT
Baseado em fatos irreais…
Eu preciso fazer vendas
usando cartões de
crédito, mas como é que
o meu sistema fala com
as operadoras?
Você usa… Sabã… ops, SOAP!
Eu resolvo o seu
problema!
Sou o protocolo padrão
de mensagens dos web
services!
Pelo menos ele não usa a cueca
por cima da roupa…
E como é que isso
resolve o meu
problema?
Os super-amigos se juntam para
resolver o problema!
WSDL – UDDI – HTTP – SMTP – FTP
Tá começando a chatear…
E como é que eu
uso esse monte de
coisa?
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.
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.
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…
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?
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.
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;
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;
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;
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;
E agora?
O que é que eu vou
usar?
REST
A nova bala de prata
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;
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
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;
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;
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;
A interface comum
Existe uma única interface para se
acessar os recursos e ela é igual para
todos;
Se você conhece um, conhece todos;
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;
Quem usa REST?
A internet toda, qualquer aplicação web
pode ser vista, de certa forma, como uma
aplicação REST;
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);
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;
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.