Your SlideShare is downloading. ×
0
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Rest Teoria E Pratica
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rest Teoria E Pratica

3,810

Published on

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,810
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
107
Comments
0
Likes
6
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. RESTful Web Services Teoria e Prática Luiz Costa luiz.costa@caelum.com.br Sergio Junior sergio.junior@caelum.com.br
  • 2. Integração O velho problema
  • 3. O Banco de Dados Solução Prática #1
  • 4. Transferência de Arquivos Solução Prática #2
  • 5. Web Services Solução Prática #3
  • 6. Como são os Web Services hoje? • Baseados na especificação WS-* • Descritores WSDL • SOAP e XML • Utilizam um estilo RPC(Remote Procedure Call) Focados em Operações
  • 7. Foco nas operações Serviço Tradicional <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> <m:ObterPedidos xmlns:m=“urn:ServicosPedidos"> <id xsi:Type=‘xsd:integer’>12553</id> </m:ObterPedidos> </env:Body> </env:Envelope>
  • 8. Foco nas operações Serviço Tradicional No matter how hard I try, I still think the WS-* stack is bloated, opaque, and insanely complex. I think it's going to be hard to understand, hard to implement, hard to interoperate, and hard to secure. Tim Bray Director of Web Technologies at Sun Microsystems. Fonte:http://qotd.me/q2004-11-02.html
  • 9. Precisamos disso tudo? Alguém já não resolveu isso?
  • 10. Web Como funciona?
  • 11. Web http://aljazeera.com/
  • 12. Web http://aljazeera.com/
  • 13. Web apenas para humanos? “Não existe nenhuma diferença essencial entre a web humana e a web programável” Leonard Richardson e Sam Ruby
  • 14. Características da Web • Tolerante a falhas • Escalável • Seguro • Baixo acoplamento
  • 15. Características da Web • Tolerante a falhas • Escalável • Seguro • Baixo acoplamento Isso não se parece com as características que queremos em nossos sistemas hoje?
  • 16. Architectural Styles and the Design of Network-based Software Architectures Dissertação de Doutorado – Roy Fielding - 2000
  • 17. REST
  • 18. REpresentational State Transfer O que é isso?
  • 19. Recursos É algo interessante para sua aplicação. Fotos, relatorios, arquivos, Lista de buracos da BR 101. Tudo é um recurso.
  • 20. Identidade de um Recurso Para ser encontrado o recurso precisa ser identificado. Todos os clientes http//exemplo.com/clientes Acessando um cliente http//exemplo.com/clientes/10 Acessando outro cliente http//exemplo.com/clientes/23
  • 21. Link os Recursos Os dados do pedido junto com o cliente <cliente> <id> 23 </id> <nome>Joana Cardoso</nome> <cpf>12345678900</cpf> <pedidos> <pedido> <id>1234</id> <data> 01/10/2009</data> <valor> 100.00 </valor> <items> <produto>33</produto> <quantidade>1</quantidade> <preco>100.00</preco> </items> </pedido> </pedidos> </cliente>
  • 22. Link os Recursos Os recursos devem estar ligados entre sí <cliente> <id>23</id> <nome>Joana Cardoso</nome> <cpf>12345678900</cpf> <pedidos> <pedido ref=’http://example.com/pedidos/ 1234’ /> </pedido> </pedidos> </cliente>
  • 23. Interface Uniforme Mantendo as coisas simples
  • 24. Interface Uniforme
  • 25. Interface Uniforme Agora o foco são os Recursos.
  • 26. Interface Uniforme Recurso /Pedidos/{Identificador} http://exemplo.com/pedidos/10 •GET() - obtém os detalhes de um pedido específico •PUT() - atualiza um pedido •POST() - adiciona um item  em um pedido •DELETE() – cancela um pedido
  • 27. Interface Uniforme Recurso /Pedidos http://exemplo.com/pedidos •GET() - lista todos os pedidos •PUT() - não é utilizado aqui •POST() - adiciona um novo pedido •DELETE() – não é utilizado aqui
  • 28. Mas e se alguma coisa der errado? Códigos de status do HTTP •100 – Continue •200 – OK •201 – Created •301 – Moved Permanently •303 – See Other •304 – Not Modified •400 – Bad Request •401 – Unauthorized •403 – Forbidden •404 – Not Found •405 – Method Not Allowed •500 – Internal Server Error
  • 29. Representações Atom
  • 30. Escolhendo uma Representação GET /pedidos/2009/11 HTTP 1.1 HOST exemplo.com Accept: application/xml 200 OK <pedido … />
  • 31. Possíveis representações do recurso: http://exemplo.com/clientes/23 XHTML XML <html> <body> <dt>id</dt> <dd>23</dd> <cliente> <id> 23 </id> <dt>nome</dt> <nome>Joana Cardoso</nome> <dd>Joana Cardoso</dd> <cpf>12345678900</cpf> <dt>cpf</dt> </cliente> <dd>12345678901</dd> </body> </html>
  • 32. Falta de Estado
  • 33. Falta de Estado • Basicamente isso se traduz em não utilizar sessões HTTP. • Sem sessões, favorecemos a escalabilidade. • Os clientes precisam aprender a viver sem sessões.
  • 34. Escalabilidade Falta de estado pode ser bom.
  • 35. Escalabilidade Falta de estado pode ser bom.
  • 36. Escalabilidade Falta de estado pode ser bom.
  • 37. Escalabilidade Falta de estado pode ser bom.
  • 38. Escalabilidade Falta de estado pode ser bom.
  • 39. Escalabilidade Falta de estado pode ser bom.
  • 40. Escalabilidade Falta de estado pode ser bom.
  • 41. Escalabilidade Falta de estado pode ser bom.
  • 42. Interface Uniforme(Web Server) Cliente (Web Client) Representação do Recursos Lógicos Recurso (e.g. XML document) Recursos físicos A arquitetura simplicidade
  • 43. Demonstração show me the code!
  • 44. Recursos Vamos identificar os recursos
  • 45. Algumas Desvantagens • Um pouco mais trabalhoso • Sem geração automática de classes, tal como as IDE’s fazem com wsdl • A maioria dos proxies web “barram” requisições PUT. Conclusão Nem tudo são flores
  • 46. Algumas Desvantagens • Um pouco mais trabalhoso • Sem geração automática de classes, tal como as IDE’s fazem com wsdl • A maioria dos proxies web “barram” requisições PUT. Algumas Vantagens • Para maioria dos servicos web o protocolo HTTP é suficiente • REST fornece múltiplas representações para os recursos. • REST tem altos níveis de interoperabilidade. Conclusão Nem tudo são flores
  • 47. Algumas Desvantagens • Um pouco mais trabalhoso • Sem geração automática de classes, tal como as IDE’s fazem com wsdl • A maioria dos proxies web “barram” requisições PUT. Algumas Vantagens • Para maioria dos servicos web o protocolo HTTP é suficiente • REST fornece múltiplas representações para os recursos. • REST tem altos níveis de interoperabilidade. “Não é porque a WEB funciona que isso significa que REST é sempre a solução correta.” “REST é modelo viável para Web Services.” Conclusão Nem tudo são flores
  • 48. Obrigado. Luiz Costa luiz.costa@caelum.com.br Sergio Junior sergio.junior@caelum.com.br FIM

×