rest teoria e pratica

49
RESTful Web Services Teoria e Prática Luiz Costa [email protected] Sergio Junior [email protected]

Upload: sergio-azevedo

Post on 05-Dec-2014

3.544 views

Category:

Technology


1 download

DESCRIPTION

 

TRANSCRIPT

Page 2: Rest Teoria E Pratica

Integração O velho problema

Page 3: Rest Teoria E Pratica

O Banco de Dados Solução Prática #1

Page 4: Rest Teoria E Pratica

Transferência de Arquivos Solução Prática #2

Page 5: Rest Teoria E Pratica

Web Services Solução Prática #3

Page 6: Rest Teoria E Pratica

• Baseados na especificação WS-*

• Descritores WSDL

• SOAP e XML

• Utilizam um estilo RPC(Remote Procedure Call)

Como são os Web Services hoje?

Focados em Operações

Page 7: Rest Teoria E Pratica

Foco nas operações Serviço Tradicional

<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>

Page 8: Rest Teoria E Pratica

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

Foco nas operações Serviço Tradicional

Page 9: Rest Teoria E Pratica

Precisamos disso tudo? Alguém já não resolveu isso?

Page 10: Rest Teoria E Pratica

Web Como funciona?

Page 11: Rest Teoria E Pratica

Web

http://aljazeera.com/

Page 12: Rest Teoria E Pratica

Web

http://aljazeera.com/

Page 13: Rest Teoria E Pratica

Web apenas para humanos?

“Não existe nenhuma diferença essencial entre a web humana e a

web programável”

Leonard Richardson e Sam Ruby

Page 14: Rest Teoria E Pratica

Características da Web

• Tolerante a falhas• Escalável• Seguro• Baixo acoplamento

Page 15: Rest Teoria E Pratica

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?

Page 16: Rest Teoria E Pratica
Page 17: Rest Teoria E Pratica

Architectural Styles andthe Design of Network-based

Software ArchitecturesDissertação de Doutorado – Roy Fielding - 2000

Page 18: Rest Teoria E Pratica

REST

Page 19: Rest Teoria E Pratica

REpresentational State

Transfer

O que é isso?

Page 20: Rest Teoria E Pratica

Recursos

É algo interessante para sua aplicação.

Fotos, relatorios, arquivos, Lista de buracos da BR 101.

Tudo é um recurso.

Page 21: Rest Teoria E Pratica

Identidade de um Recurso

Para ser encontrado o recurso precisa ser identificado.

Todos os clienteshttp//exemplo.com/clientes

Acessando um clientehttp//exemplo.com/clientes/10

Acessando outro clientehttp//exemplo.com/clientes/23

Page 22: Rest Teoria E Pratica

Link os Recursos

Os dados 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>

Page 23: Rest Teoria E Pratica

Link os Recursos

Os recursos 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>

Page 24: Rest Teoria E Pratica

Interface Uniforme Mantendo as coisas simples

Page 25: Rest Teoria E Pratica

Interface Uniforme

Page 26: Rest Teoria E Pratica

Agora o foco são os Recursos.

Interface Uniforme

Page 27: Rest Teoria E Pratica

Interface Uniforme Recurso /Pedidos/{Identificador}

•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

http://exemplo.com/pedidos/10

Page 28: Rest Teoria E Pratica

Interface Uniforme Recurso /Pedidos

•GET() - lista todos os pedidos

•PUT() - não é utilizado aqui

•POST() - adiciona um novo pedido

•DELETE() – não é utilizado aqui

http://exemplo.com/pedidos

Page 29: Rest Teoria E Pratica

Mas e se alguma coisa der errado?

•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

Códigos de status do HTTP

Page 30: Rest Teoria E Pratica

Representações

Atom

Page 31: Rest Teoria E Pratica

Escolhendo uma RepresentaçãoGET /pedidos/2009/11 HTTP 1.1

HOST exemplo.comAccept: application/xml

200 OK<pedido … />

Page 32: Rest Teoria E Pratica

XHTML XML

<html><body><dt>id</dt> <dd>23</dd><dt>nome</dt> <dd>Joana Cardoso</dd><dt>cpf</dt> <dd>12345678901</dd></body></html>

<cliente> <id> 23 </id> <nome>Joana Cardoso</nome> <cpf>12345678900</cpf></cliente>

Possíveis representações do recurso:http://exemplo.com/clientes/23

Page 33: Rest Teoria E Pratica

Falta de Estado

Page 34: Rest Teoria E Pratica

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.

Page 35: Rest Teoria E Pratica

Escalabilidade Falta de estado pode ser bom.

Page 36: Rest Teoria E Pratica

Escalabilidade Falta de estado pode ser bom.

Page 37: Rest Teoria E Pratica

Escalabilidade Falta de estado pode ser bom.

Page 38: Rest Teoria E Pratica

Escalabilidade Falta de estado pode ser bom.

Page 39: Rest Teoria E Pratica

Escalabilidade Falta de estado pode ser bom.

Page 40: Rest Teoria E Pratica

Escalabilidade Falta de estado pode ser bom.

Page 41: Rest Teoria E Pratica

Escalabilidade Falta de estado pode ser bom.

Page 42: Rest Teoria E Pratica

Escalabilidade Falta de estado pode ser bom.

Page 43: Rest Teoria E Pratica

A arquitetura simplicidade

Recursos físicos

Recursos Lógicos

Interface Uniforme(Web Server)

Representação do Recurso

(e.g. XML document)

Cliente(Web Client)

Page 44: Rest Teoria E Pratica

Demonstração show me the code!

Page 45: Rest Teoria E Pratica

Recursos Vamos identificar os recursos

Page 46: Rest Teoria E Pratica

Conclusão Nem tudo são flores

Algumas Desvantagens• Um pouco 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.

Page 47: Rest Teoria E Pratica

Conclusão Nem tudo são flores

Algumas Desvantagens• Um pouco 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.

Page 48: Rest Teoria E Pratica

Conclusão Nem tudo são flores

Algumas Desvantagens• Um pouco 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.”