4. Protocolos da Internet
smtp: email
nntp: fórum de
ftp: arquivos
discussão
Do REST Ao RESTful
Www.caelum.com.br
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. 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. 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. 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. E hoje?
smtp: email
bittorrent: arquivos
irc, im: chat
ssh: acesso remoto
Do REST Ao RESTful
Www.caelum.com.br
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. www é um sistema de
documentos hypertext
Do REST Ao RESTful
Www.caelum.com.br
12. 2000 - Roy Fielding
why the web? why?
Do REST Ao RESTful
Www.caelum.com.br
13. protocolos
usando http
xml-rpc
soap
Do REST Ao RESTful
Www.caelum.com.br
14. http != www
xml-rpc usa http
soap usa http
mas e a tal da hypermedia?
Do REST Ao RESTful
Www.caelum.com.br
16. Leonard Richardson’s
maturity model
0 - nada
1 - uri
2 - http
3 - html
Do REST Ao RESTful
Www.caelum.com.br
17. nível zero
1 uri
1 verbo http
Do REST Ao RESTful
Www.caelum.com.br
18. nível um
diversas uris
Do REST Ao RESTful
Www.caelum.com.br
19. nível um - uris
mashups
bookmarks
addressability
tudo em uma requisição
visibility
stateless
Do REST Ao RESTful
Www.caelum.com.br
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. nível dois
diversas uris
http
Do REST Ao RESTful
Www.caelum.com.br
22. nível dois
http é o protocolo de aplicação
web É a API
Do REST Ao RESTful
Www.caelum.com.br
23. nível dois - http
stateless
cache, proxies
fault tolerant
scalability
locking
Do REST Ao RESTful
Www.caelum.com.br
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. nível três
diversas uris
http
html (hypermedia)
Do REST Ao RESTful
Www.caelum.com.br
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Do REST ao RESTFul
Guilherme Silveira Adriano Almeida
@guilhermecaelum @adrianoalmeida7
Do REST Ao RESTful
Www.caelum.com.br
Notas do Editor
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&#xF3; recurso &#xE9; complicado de lidar: tem um restaurante s&#xF3;. qual ta com pau?
diversos recursos &#xE9; mais facil de entender. divida seu sistema em diversos
cache: post nao cacheia! BACK funciona!
um s&#xF3; recurso &#xE9; complicado de lidar: tem um restaurante s&#xF3;. diversos recursos &#xE9; 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&#xE3;o readiciona
nao precisa ficar criando uma biblioteca para cada protocolo proprietario que inventamos (a API nossa)... afinal a API &#xC9; 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