Transferir como PDF, PPTX
Carregado porSergio Azevedo
Rest Teoria E Pratica
O documento discute os princípios de arquitetura RESTful para web services. Ele explica que REST se baseia nos recursos identificados por URIs e na interface uniforme do HTTP para manipular esses recursos através de métodos como GET, PUT, POST e DELETE. A arquitetura RESTful oferece características como tolerância a falhas, escalabilidade e interoperabilidade que tornam o protocolo HTTP adequado para a maioria dos serviços web.
Rest Teoria E Pratica
- 1. RESTful Web Services Teoriae 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 deDados 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 osWeb 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çoTradicional <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çoTradicional 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 parahumanos? “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?
- 17. Architectural Styles and theDesign of Network-based Software Architectures Dissertação de Doutorado – Roy Fielding - 2000
- 18.
- 19. REpresentational State Transfer O que é isso?
- 20. Recursos É algo interessantepara sua aplicação. Fotos, relatorios, arquivos, Lista de buracos da BR 101. Tudo é um recurso.
- 21. Identidade de umRecurso 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
- 22. Link os Recursos Osdados 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>
- 23. Link os Recursos Osrecursos 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>
- 24. Interface Uniforme Mantendo as coisas simples
- 25.
- 26. Interface Uniforme Agora o foco são os Recursos.
- 27. 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
- 28. 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
- 29. Mas e sealguma 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
- 30. Representações Atom
- 31. Escolhendo uma Representação GET /pedidos/2009/11 HTTP 1.1 HOST exemplo.com Accept: application/xml 200 OK <pedido … />
- 32. Possíveis representações dorecurso: 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>
- 33.
- 34. 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.
- 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. Escalabilidade Falta de estado pode ser bom.
- 43. Interface Uniforme(Web Server) Cliente (Web Client) Representação do Recursos Lógicos Recurso (e.g. XML document) Recursos físicos A arquitetura simplicidade
- 44. Demonstração show me the code!
- 45. Recursos Vamos identificar os recursos
- 46. Algumas Desvantagens • Umpouco 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
- 47. Algumas Desvantagens • Umpouco 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
- 48. Algumas Desvantagens • Umpouco 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
- 49. Obrigado. Luiz Costa luiz.costa@caelum.com.br Sergio Junior sergio.junior@caelum.com.br FIM