Caelum 2009 Do Rest Ao Restful

2,755 views
2,668 views

Published on

Apresentação sobre Rest/Restful e geral sobre o Restfulie.

Published in: Technology, Design
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,755
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
58
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • ANTIGAMENTE home banking era DIAL UP!!!
  • ao criar uma aplicacao nova: internet banking: todo mundo continua funcionando: uniform interface... pq o browser sabe como aplicacoes que usam www e http funcionam.
  • xml-rpc: dave winer
    soap: microsoft
    clientes automatizados fazer requisicoes http, como um ser humano estava fazendo
  • o quanto voce usa da web no seu sistema?
  • xml-rpc
    most soap services
    typical flash based websites
    makes you feel the web is not the web
  • flickr web services, delicious,amazon ecs, rails ERAM assim, mudaram
  • um só recurso é complicado de lidar: tem um restaurante só. qual ta com pau?
    diversos recursos é mais facil de entender. divida seu sistema em diversos
    cache: post nao cacheia! BACK funciona!
  • um só recurso é complicado de lidar: tem um restaurante só. diversos recursos é mais facil de entender. divida seu sistema em diversos
  • flickr web services, delicious,amazon s3: melhor exemplo, rails hoje em dia
  • http diz o que eh para ser feito atraves dos metodos e da URI (aonde eh para ser feito)
    web API != soap onde o XML eh a api, perde visibility... ai cria coisas como ESBs para ver isso
  • stateless: estado do cliente x aplicacao, cache: escala, get/put: idempotente, scalability: stateless, post+if = locking. stateless: visibility (ta tudo la! vc sabe o q esta acontecendo, nada escondido: intermediario pode atuar): reliability: esta tudo la, ele nao assume coisas erradas
  • cookie: vc nao tem so a URI identificado a coisa
    extensao: se ocliente ou o layer intermediario nao compreende, nao funciona.
  • recurso descreve suas CAPABILITIES e CONEXOES
    exemplos: www, atompub
  • se vc deixa o schema totalmente fixo, vc deixa um strong coupling... ilusao de que sao desacoplados
    eh OPCIONAL (ou dificil) manter compatibilidade entre versoes: exemplo AMAZON
  • constraint: vc PRECISA nao se preocupar com a evolucao dele. se vc quiser, vc usa, se vc nao sabe, tudo bem... mas eh o padrao.
    media type: xml com link nao existe, tem que ser vendor specific: vnd/a+xml
    LOOSE COUPLING: tem coupling mas eh leve.HIGH: vc nao permite evolucao. essa eh a diferenca entre webservices com wsdl por exemplo ou outro que tenha uma especificacao, mas aberta para evoluir. html esta aberto para evoluir, imagine se todas as paginas tivessem que ter menu em cima etc?nao eh solucao para curto, eh solucao para longo prazo: solucao estrategica, nao de ti
  • se vc ignora, vc tira o strong coupling... e consegue evoluir em paralelo
    eh assim que eh a web hoje em dia
    evoluir a LONGO prazo do que evoluir a CURTO PRAZO
  • constraint: vc PRECISA nao se preocupar com a evolucao dele. se vc quiser, vc usa, se vc nao sabe, tudo bem... mas eh o padrao.
    media type: xml com link nao existe, tem que ser vendor specific: vnd/a+xml
  • constraint: vc PRECISA nao se preocupar com a evolucao dele. se vc quiser, vc usa, se vc nao sabe, tudo bem... mas eh o padrao.
    media type: xml com link nao existe, tem que ser vendor specific: vnd/a+xml
  • constraint: vc PRECISA nao se preocupar com a evolucao dele. se vc quiser, vc usa, se vc nao sabe, tudo bem... mas eh o padrao.
    media type: xml com link nao existe, tem que ser vendor specific: vnd/a+xml
  • usa PUT mas faz um IF para verificar se nao foi alterada
  • usa PUT não readiciona
  • nao precisa ficar criando uma biblioteca para cada protocolo proprietario que inventamos (a API nossa)... afinal a API É A WEB
  • comportamento novo NAO deve quebrar o que ja existe
  • constraint: vc PRECISA nao se preocupar com a evolucao dele. se vc quiser, vc usa, se vc nao sabe, tudo bem... mas eh o padrao.
    media type: xml com link nao existe, tem que ser vendor specific: vnd/a+xml
  • constraint: vc PRECISA nao se preocupar com a evolucao dele. se vc quiser, vc usa, se vc nao sabe, tudo bem... mas eh o padrao.
    media type: xml com link nao existe, tem que ser vendor specific: vnd/a+xml
  • Caelum 2009 Do Rest Ao Restful

    1. 1. Do REST ao RESTFul Guilherme Silveira Adriano Almeida @guilhermecaelum @adrianoalmeida7 Do REST Ao RESTful Www.caelum.com.br
    2. 2. Protocolos da Internet ftp: arquivos Do REST Ao RESTful Www.caelum.com.br
    3. 3. Protocolos da Internet smtp: email ftp: arquivos Do REST Ao RESTful Www.caelum.com.br
    4. 4. Protocolos da Internet smtp: email nntp: fórum de ftp: arquivos discussão Do REST Ao RESTful Www.caelum.com.br
    5. 5. Protocolos da Internet smtp: email irc: chat nntp: fórum de discussão ftp: arquivos Do REST Ao RESTful Www.caelum.com.br
    6. 6. Protocolos da Internet smtp: email irc: chat telnet: acesso remoto nntp: fórum de discussão ftp: arquivos Do REST Ao RESTful Www.caelum.com.br
    7. 7. Protocolos da Internet smtp: email irc: chat telnet: acesso remoto gopher, www: hipertexto nntp: fórum de discussão ftp: arquivos Do REST Ao RESTful Www.caelum.com.br
    8. 8. Protocolos da Internet smtp: email irc: chat veronica: busca em gopher wais: busca em banco de dados archie: busca em ftp telnet: acesso remoto gopher, www: hipertexto nntp: fórum de discussão ftp: arquivos prospero: directory services Do REST Ao RESTful Www.caelum.com.br
    9. 9. E hoje? smtp: email bittorrent: arquivos irc, im: chat ssh: acesso remoto Do REST Ao RESTful Www.caelum.com.br
    10. 10. E hoje? home banking: www compras: www calendário: www email: www chat: www documentos: www conteúdo restrito: www Do REST Ao RESTful Www.caelum.com.br
    11. 11. www é um sistema de documentos hypertext Do REST Ao RESTful Www.caelum.com.br
    12. 12. 2000 - Roy Fielding why the web? why? Do REST Ao RESTful Www.caelum.com.br
    13. 13. protocolos usando http xml-rpc soap Do REST Ao RESTful Www.caelum.com.br
    14. 14. http != www xml-rpc usa http soap usa http mas e a tal da hypermedia? Do REST Ao RESTful Www.caelum.com.br
    15. 15. características da web uri http html Do REST Ao RESTful Www.caelum.com.br
    16. 16. Leonard Richardson’s maturity model 0 - nada 1 - uri 2 - http 3 - html Do REST Ao RESTful Www.caelum.com.br
    17. 17. nível zero 1 uri 1 verbo http Do REST Ao RESTful Www.caelum.com.br
    18. 18. nível um diversas uris Do REST Ao RESTful Www.caelum.com.br
    19. 19. nível um - uris mashups bookmarks addressability tudo em uma requisição visibility stateless Do REST Ao RESTful Www.caelum.com.br
    20. 20. nível um - uris http://caelum.com.br/my_user_id bad usage: id identifica client state bad usage: body diz o que executar visibility-- stateless-- Do REST Ao RESTful Www.caelum.com.br
    21. 21. nível dois diversas uris http Do REST Ao RESTful Www.caelum.com.br
    22. 22. nível dois http é o protocolo de aplicação web É a API Do REST Ao RESTful Www.caelum.com.br
    23. 23. nível dois - http stateless cache, proxies fault tolerant scalability locking Do REST Ao RESTful Www.caelum.com.br
    24. 24. nível dois - http bad usage: cookie (perde adressability) bad usage: extensões obrigatórias (perde compatibilidade) Do REST Ao RESTful Www.caelum.com.br
    25. 25. nível três diversas uris http html (hypermedia) Do REST Ao RESTful Www.caelum.com.br
    26. 26. schema fixo fail fast: die die die!!! strong coupling every new release: all clients must change Do REST Ao RESTful Www.caelum.com.br
    27. 27. nível três - hypermedia usar um formato comum ex: html, atom, vcal permite o servidor evoluir permite o cliente evoluir loose coupling Do REST Ao RESTful Www.caelum.com.br
    28. 28. schema dinâmico ignore o que você não conhece loose coupling exemplo: versões novas de html Do REST Ao RESTful Www.caelum.com.br
    29. 29. na prática: ruby class Order acts_as_restfulie def following_transitions transitions = [] transitions << :pay transitions end end Do REST Ao RESTful Www.caelum.com.br
    30. 30. na prática: ruby <order> <client> <name>guilherme silveira</name> </client> Do REST Ao RESTful <link rel=”pay” href=”.../order/3/pay” /> </order> Www.caelum.com.br
    31. 31. na prática: ruby client order = Order.from_web “.../order/3” payment = Payment.new payment.card.number = 4444 payment.card.holder = “guilherme” receipt = order.pay payment Do REST Ao RESTful Www.caelum.com.br
    32. 32. prática: locking order = Order.from_web “.../order/3” order.add(item).in_case :unchanged # usa PUT Do REST Ao RESTful Www.caelum.com.br
    33. 33. prática: fault tolerant order = Order.from_web “.../order/3” order.add(item) # usa PUT order.add(item) # usa PUT, não irá readicionar Do REST Ao RESTful Www.caelum.com.br
    34. 34. prática: one application protocol user = Flickr.from_web “.../users/guilhermesilveira” user.photos.add photo # POST user.account.upgrade # POST Do REST Ao RESTful Www.caelum.com.br
    35. 35. prática: loose coupling user = Flickr.from_web “.../users/guilhermesilveira” user.movies.add movie # comportamento novo user.photos.add photo # POST user.account.upgrade # POST Do REST Ao RESTful Www.caelum.com.br
    36. 36. na prática: java public class Order implements StateResource { public List getFollowingTransitions(Restfulie control) { control.transition(OrderController.class).pay(); return control.getTransitions(); } } Do REST Ao RESTful Www.caelum.com.br
    37. 37. na prática: java client Order order = resource(“.../order/3”); Payment payment = new Payment(...); Receipt receipt = resource(order).getTransition(“pay”).execute(payment) Do REST Ao RESTful Www.caelum.com.br
    38. 38. restfulie - java - ruby on rails outras linguagens? www.github.com/caelum/restfulie www.github.com/caelum/restfulie-java Do REST Ao RESTful Www.caelum.com.br
    39. 39. Do REST ao RESTFul Guilherme Silveira Adriano Almeida @guilhermecaelum @adrianoalmeida7 Do REST Ao RESTful Www.caelum.com.br

    ×