rest teoria e pratica
Post on 06-Jun-2015
907 Views
Preview:
DESCRIPTION
TRANSCRIPT
RESTful Web ServicesTeoria e Prática
Luiz Costaluiz.costa@caelum.com.br
Sergio Juniorsergio.junior@caelum.com.br
Integração O velho problema
O Banco de Dados Solução Prática #1
Transferência de Arquivos
Solução Prática #2
Web Services Solução Prática #3
• 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
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>
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
Precisamos disso tudo?
Alguém já não resolveu isso?
Web Como funciona?
Web
http://aljazeera.com/
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
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?
Isso não se parece com as características que queremos em
nossos sistemas hoje?
Architectural Styles andArchitectural Styles andthe Design of Network-based the Design of Network-based
Software ArchitecturesSoftware Architectures
Architectural Styles andArchitectural Styles andthe Design of Network-based the Design of Network-based
Software ArchitecturesSoftware ArchitecturesDissertação de Doutorado – Roy Fielding - 2000Dissertação de Doutorado – Roy Fielding - 2000Dissertação de Doutorado – Roy Fielding - 2000Dissertação de Doutorado – Roy Fielding - 2000
REST
REpresentational
State Transfer
O que é isso?
Recursos
É algo interessante para sua aplicação.
Fotos, relatorios, arquivos, Lista de buracos da BR 101.
Tudo é um recurso.
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
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>
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>
Interface Uniforme Mantendo as coisas simples
Agora o foco são os Recursos.
Agora o foco são os Recursos.
Interface Uniforme
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/10http://exemplo.com/pedidos/10
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/pedidoshttp://exemplo.com/pedidos
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
Representações
Atom
Escolhendo uma RepresentaçãoGET /pedidos/2009/11 HTTP 1.1
HOST exemplo.comAccept: application/xml
200 OK<pedido … />
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
Falta de Estado
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.
Escalabilidade Falta de estado pode ser bom.
Escalabilidade Falta de estado pode ser bom.
A arquitetura simplicidade
Recursos físicos
Recursos Lógicos
Interface Uniforme(Web Server)
Representação do Recurso
(e.g. XML document)
Cliente(Web Client)
Demonstração show me the code!
Recursos Vamos identificar os recursos
Conclusão Nem tudo são flores
Algumas DesvantagensAlgumas 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 Não é porque a WEB funciona que isso significa que REST é sempre a solução correta.”que REST é sempre a solução correta.”
““REST é modelo viável para Web Services.”REST é modelo viável para Web Services.”
FIM
Luiz Costa luiz.costa@caelum.com.br
Sergio Junior sergio.junior@caelum.com.br
Obrigado.Obrigado.
top related