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.
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
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
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
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 é stateless
HTTP é a nossa API
http headers
http é stateless
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ã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 É 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