O documento discute os princípios de arquitetura RESTful para web services. Ele explica que REST se baseia nos recursos identificados por URIs e na interface uniforme do HTTP para manipular esses recursos através de métodos como GET, PUT, POST e DELETE. A arquitetura RESTful oferece características como tolerância a falhas, escalabilidade e interoperabilidade que tornam o protocolo HTTP adequado para a maioria dos serviços web.

1. RESTful Web Services
Teoria e Prática
Luiz Costa
luiz.costa@caelum.com.br
Sergio Junior
sergio.junior@caelum.com.br

2. Integração O velho problema

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

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

5. Web Services Solução Prática #3

6. Como são os Web Services hoje?
• Baseados na especificação WS-*
• Descritores WSDL
• SOAP e XML
• Utilizam um estilo RPC(Remote
Procedure Call)
Focados em Operações

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

8. Foco nas operações
Serviço Tradicional
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

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

10. Web Como funciona?

11. Web
http://aljazeera.com/

12. Web
http://aljazeera.com/

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

14. Características da Web
• Tolerante a falhas
• Escalável
• Seguro
• Baixo acoplamento

15. 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?

17. Architectural Styles and
the Design of Network-based
Software Architectures
Dissertação de Doutorado – Roy Fielding - 2000

18. REST

19. REpresentational
State
Transfer
O que é isso?

20. Recursos
É algo interessante para sua
aplicação.
Fotos, relatorios, arquivos,
Lista de buracos da BR 101.
Tudo é um recurso.

21. Identidade de um Recurso
Para ser encontrado o recurso precisa ser
identificado.
Todos os clientes
http//exemplo.com/clientes
Acessando um cliente
http//exemplo.com/clientes/10
Acessando outro cliente
http//exemplo.com/clientes/23

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

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

24. Interface Uniforme Mantendo as coisas simples

25. Interface Uniforme

26. Interface Uniforme
Agora o foco são os
Recursos.

27. Interface Uniforme
Recurso /Pedidos/{Identificador}
http://exemplo.com/pedidos/10
•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

28. Interface Uniforme
Recurso /Pedidos
http://exemplo.com/pedidos
•GET() - lista todos os pedidos
•PUT() - não é utilizado aqui
•POST() - adiciona um novo pedido
•DELETE() – não é utilizado aqui

29. Mas e se alguma coisa der errado?
Códigos de status do HTTP
•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

30. Representações
Atom

31. Escolhendo uma Representação
GET /pedidos/2009/11 HTTP 1.1
HOST exemplo.com
Accept: application/xml
200 OK
<pedido … />

32. Possíveis representações do recurso:
http://exemplo.com/clientes/23
XHTML XML
<html>
<body>
<dt>id</dt>
<dd>23</dd> <cliente>
<id> 23 </id>
<dt>nome</dt>
<nome>Joana Cardoso</nome>
<dd>Joana Cardoso</dd> <cpf>12345678900</cpf>
<dt>cpf</dt> </cliente>
<dd>12345678901</dd>
</body>
</html>

33. Falta de Estado

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

35. Escalabilidade Falta de estado pode ser bom.

36. Escalabilidade Falta de estado pode ser bom.

37. Escalabilidade Falta de estado pode ser bom.

38. Escalabilidade Falta de estado pode ser bom.

39. Escalabilidade Falta de estado pode ser bom.

40. Escalabilidade Falta de estado pode ser bom.

41. Escalabilidade Falta de estado pode ser bom.

42. Escalabilidade Falta de estado pode ser bom.

43. Interface Uniforme(Web
Server)
Cliente
(Web Client)
Representação do Recursos Lógicos
Recurso
(e.g. XML document)
Recursos físicos
A arquitetura simplicidade

44. Demonstração show me the code!

45. Recursos Vamos identificar os
recursos

46. 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.
Conclusão Nem tudo são flores

47. 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.
Conclusão Nem tudo são flores

48. 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.”
Conclusão Nem tudo são flores

49. Obrigado.
Luiz Costa
luiz.costa@caelum.com.br
Sergio Junior
sergio.junior@caelum.com.br
FIM