Protocolos da Internet e REST: Evolução e Princípios
•Als KEY, PDF herunterladen•
2 gefällt mir•1,490 views
O documento discute os requisitos não funcionais de REST e como eles tornam a arquitetura escalável e flexível. Ele explora como protocolos da web evoluíram para atender requisitos como alta performance, disponibilidade e evolução contínua sem quebrar clientes. A arquitetura REST é discutida como uma solução para esses requisitos através de características como URI, HTTP e hipermídia.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Protocolos da Internet e REST: Evolução e Princípios
Ähnlich wie Protocolos da Internet e REST: Evolução e Princípios (20)
Mehr von Guilherme Silveira
Mehr von Guilherme Silveira (20)
Protocolos da Internet e REST: Evolução e Princípios
- 1. REST: Arquitetura Irresponsável? Guilherme Silveira @guilhermecaelum REST Arquitetura Irresponsável Www.caelum.com.br
- 3. Requisitos não funcionais ✤ protocolo de transferência de dados amplamente utilizado
- 4. Requisitos não funcionais ✤ protocolo de transferência de dados amplamente utilizado ✤ escalabilidade
- 5. Requisitos não funcionais ✤ protocolo de transferência de dados amplamente utilizado ✤ escalabilidade ✤ performance alta
- 6. Requisitos não funcionais ✤ protocolo de transferência de dados amplamente utilizado ✤ escalabilidade ✤ performance alta ✤ alta disponibilidade
- 7. Requisitos não funcionais ✤ protocolo de transferência de dados amplamente utilizado ✤ escalabilidade ✤ performance alta ✤ alta disponibilidade ✤ permitir evolução sem parar o sistema
- 8. Requisitos não funcionais ✤ protocolo de transferência de dados amplamente utilizado ✤ escalabilidade ✤ performance alta ✤ alta disponibilidade ✤ permitir evolução sem parar o sistema ✤ permitir evolução sem quebrar clientes
- 9. Requisitos não funcionais ✤ protocolo de transferência de dados amplamente utilizado ✤ escalabilidade ✤ performance alta ✤ alta disponibilidade ✤ permitir evolução sem parar o sistema ✤ permitir evolução sem quebrar clientes ✤ segurança
- 10. Top hits? ✤ protocolo de transferência de dados amplamente utilizado ✤ escalabilidade ✤ performance alta ✤ alta disponibilidade ✤ permitir evolução sem parar o sistema ✤ permitir evolução sem quebrar clientes ✤ segurança
- 11. Top hits? ✤ http ✤ escalabilidade ✤ performance alta ✤ alta disponibilidade ✤ permitir evolução sem parar o sistema ✤ permitir evolução sem quebrar clientes ✤ segurança
- 12. Top hits? ✤ http ✤ web: caches ✤ performance alta ✤ alta disponibilidade ✤ permitir evolução sem parar o sistema ✤ permitir evolução sem quebrar clientes ✤ segurança
- 13. Top hits? ✤ http ✤ web: caches ✤ web: proxies, localização geográfica ✤ alta disponibilidade ✤ permitir evolução sem parar o sistema ✤ permitir evolução sem quebrar clientes ✤ segurança
- 14. Top hits? ✤ http ✤ web: caches ✤ web: proxies, localização geográfica ✤ http: load balancers “comoditizados” ✤ permitir evolução sem parar o sistema ✤ permitir evolução sem quebrar clientes ✤ segurança
- 15. Top hits? ✤ http ✤ web: caches ✤ web: proxies, localização geográfica ✤ http: load balancers “comoditizados” ✤ http: load balancers ✤ permitir evolução sem quebrar clientes ✤ segurança
- 16. Top hits? ✤ http ✤ web: caches ✤ web: proxies, localização geográfica ✤ http: load balancers “comoditizados” ✤ http: load balancers ✤ web: html e loosely coupling ✤ segurança
- 17. Top hits? ✤ http ✤ web: caches ✤ web: proxies, localização geográfica ✤ http: load balancers “comoditizados” ✤ http: load balancers ✤ web: html e loosely coupling ✤ tls: https
- 18. “O” sistema escalável: a web ✤ http ✤ web: caches ✤ web: proxies, localização geográfica ✤ http: load balancers “comoditizados” ✤ http: load balancers ✤ web: html e loosely coupling ✤ tls: https
- 19. Protocolos da Internet ftp: arquivos REST Arquitetura Irresponsável Www.caelum.com.br
- 20. Protocolos da Internet smtp: email ftp: arquivos REST Arquitetura Irresponsável Www.caelum.com.br
- 21. Protocolos da Internet smtp: email nntp: fórum de ftp: arquivos discussão REST Arquitetura Irresponsável Www.caelum.com.br
- 22. Protocolos da Internet smtp: email irc: chat nntp: fórum de discussão ftp: arquivos REST Arquitetura Irresponsável Www.caelum.com.br
- 23. Protocolos da Internet smtp: email irc: chat telnet: acesso remoto nntp: fórum de discussão ftp: arquivos REST Arquitetura Irresponsável Www.caelum.com.br
- 24. Protocolos da Internet smtp: email irc: chat telnet: acesso remoto gopher, www: hipertexto nntp: fórum de discussão ftp: arquivos REST Arquitetura Irresponsável Www.caelum.com.br
- 25. 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 REST Arquitetura Irresponsável Www.caelum.com.br
- 26. E hoje? REST Arquitetura Irresponsável Www.caelum.com.br
- 27. E hoje? smtp: email bittorrent: arquivos irc, im: chat ssh: acesso remoto REST Arquitetura Irresponsável Www.caelum.com.br
- 28. E hoje? home banking: www compras: www calendário: www email: www chat: www documentos: www conteúdo restrito: www sexo: www REST Arquitetura Irresponsável Www.caelum.com.br
- 29. 2000 - Roy Fielding why the web? why? REST Arquitetura Irresponsável Www.caelum.com.br
- 30. protocolos usando http xml-rpc soap REST Arquitetura Irresponsável Www.caelum.com.br
- 31. http != www REST Arquitetura Irresponsável Www.caelum.com.br
- 32. Solução clássica guj.com.br 2 milhões de page views - jetty - Nginx
- 33. Solução moderna caelum.com.br cloud - google app engine - amazon - locaweb - engineyard
- 34. Solução contemporânea REST na web
- 35. características da web uri http hypermedia REST Arquitetura Irresponsável Www.caelum.com.br
- 36. Leonard Richardson’s maturity model 0 - nada 1 - uri 2 - http 3 - hypermedia REST Arquitetura Irresponsável Www.caelum.com.br
- 37. Loosely Coupled REST Arquitetura Irresponsável Www.caelum.com.br
- 38. class Order acts_as_restfulie do |t| t << :pay end end na prática: ruby REST Arquitetura Irresponsável Www.caelum.com.br
- 39. na prática: ruby <order> <client> <name>guilherme silveira</name> </client> <link rel=”pay” href=”.../order/3/pay” /> </order> REST Arquitetura Irresponsável Www.caelum.com.br
- 40. Addressability REST Arquitetura Irresponsável Www.caelum.com.br
- 41. Visibility REST Arquitetura Irresponsável Www.caelum.com.br
- 42. Scalability REST Arquitetura Irresponsável Www.caelum.com.br
- 43. na prática: ruby cache_info = {:etag => resource} cache_info[:last_modified] = resource.updated_at if stale? cache_info options[:controller] = self render :xml => resource.to_xml(options) end REST Arquitetura Irresponsável Www.caelum.com.br
- 44. na prática: ruby # cache-control news = Restfulie.at(uri).get news.self.self.self.self REST Arquitetura Irresponsável Www.caelum.com.br
- 45. na prática: ruby # etags order = Restfulie.at(uri).get order.self.self.self.self.self order.cancel REST Arquitetura Irresponsável Www.caelum.com.br
- 46. Fault tolerant REST Arquitetura Irresponsável Www.caelum.com.br
- 47. prática: fault tolerant order = Order.from_web “.../order/3” order.add(item) # usa PUT order.add(item) # usa PUT, não irá readicionar REST Arquitetura Irresponsável Www.caelum.com.br
- 48. Segurança REST Arquitetura Irresponsável Www.caelum.com.br
- 49. Search - indexing REST Arquitetura Irresponsável Www.caelum.com.br
- 50. $$$ e os custos? $$$ REST Arquitetura Irresponsável Www.caelum.com.br
- 51. huge vendor stack REST Arquitetura Irresponsável Www.caelum.com.br
- 52. middleware opensource REST Arquitetura Irresponsável Www.caelum.com.br
- 53. vendor lock-in REST Arquitetura Irresponsável Www.caelum.com.br
- 54. web REST Arquitetura Irresponsável Www.caelum.com.br
- 55. 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 REST Arquitetura Irresponsável Www.caelum.com.br
- 56. prática: one application protocol user = Flickr.from_web “.../users/guilhermesilveira” user.photos.add photo # POST user.account.upgrade # POST REST Arquitetura Irresponsável Www.caelum.com.br
- 57. na prática: github REST Arquitetura Irresponsável Www.caelum.com.br
- 58. na prática: github quero watchear um projeto? REST Arquitetura Irresponsável Www.caelum.com.br
- 59. na prática: github quero watchear um projeto? GET/POST /projeto/watch GET/POST /projeto/unwatch REST Arquitetura Irresponsável Www.caelum.com.br
- 60. na prática: github quero watchear um projeto? GET/POST /projeto/watch GET/POST /projeto/unwatch POST /projeto/watcher ==> created /projeto/watcher/545 DELETE /projeto/watcher/545 REST Arquitetura Irresponsável Www.caelum.com.br
- 61. restfulie - ruby - java - c# - php? - erlang? - outras linguagens? http://restfulie.caelum.com.br REST Arquitetura Irresponsável Www.caelum.com.br
- 62. REST Arquitetura Irresponsável? Guilherme Silveira @guilhermecaelum REST Arquitetura Irresponsável Www.caelum.com.br
Hinweis der Redaktion
- ANTIGAMENTE home banking era DIAL UP!!!
- xml-rpc: dave winer soap: microsoft clientes automatizados fazer requisicoes http, como um ser humano estava fazendo
- xml-rpc usa parte do http soap usa parte do http mas e a tal da hypermedia? e o resto do http?
- o quanto voce usa da web no seu sistema?
- evolue sem problemas
- 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
- URI HTTP &#xE9; stateless
- HTTP &#xE9; a nossa API http headers http &#xE9; stateless
- URI HTTP &#xE9; stateless - http response codes - http headers - cache - load balancing
- 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
- verbos idempotentes
- usa PUT n&#xE3;o readiciona
- - https - oauth
- o quanto voce usa da web no seu sistema?
- verbos idempotentes
- verbos idempotentes
- verbos idempotentes
- verbos idempotentes
- verbos idempotentes
- comportamento novo NAO deve quebrar o que ja existe
- nao precisa ficar criando uma biblioteca para cada protocolo proprietario que inventamos (a API nossa)... afinal a API &#xC9; A WEB
- 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