Do Rest Ao Restfull - Rio Jug
•Télécharger en tant que KEY, PDF•
7 j'aime•1,069 vues
Como tornar seus serviços RESTful. Como e porque usar hypermedia. O que é HATEOAS?
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (17)
Similaire à Do Rest Ao Restfull - Rio Jug
Similaire à Do Rest Ao Restfull - Rio Jug (20)
Do Rest Ao Restfull - Rio Jug
- 1. Do REST ao RESTful Luiz Costa luiz.costa@caelum.com.br @gutomcosta Sergio Junior sergio.junior@caelum.com.br @sergioazevedo
- 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. 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
- 8. Requisitos não Funcionais ✤ http ✤ escalabilidade ✤ performance alta ✤ alta disponibilidade ✤ permitir evolução sem parar o sistema ✤ permitir evolução sem quebrar clientes ✤ segurança
- 9. Requisitos não Funcionais ✤ http ✤ web: caches ✤ performance alta ✤ alta disponibilidade ✤ permitir evolução sem parar o sistema ✤ permitir evolução sem quebrar clientes ✤ segurança
- 10. Requisitos não Funcionais ✤ 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
- 11. Requisitos não Funcionais ✤ http ✤ web: caches ✤ web: proxies, localização geográfica ✤ http: load balancers ✤ permitir evolução sem parar o sistema ✤ permitir evolução sem quebrar clientes ✤ segurança
- 12. Requisitos não Funcionais ✤ http ✤ web: caches ✤ web: proxies, localização geográfica ✤ http: load balancers ✤ http: load balancers ✤ permitir evolução sem quebrar clientes ✤ segurança
- 13. Requisitos não Funcionais ✤ http ✤ web: caches ✤ web: proxies, localização geográfica ✤ http: load balancers ✤ http: load balancers ✤ web: html e loosely coupling ✤ segurança
- 14. Requisitos não Funcionais ✤ http ✤ web: caches ✤ web: proxies, localização geográfica ✤ http: load balancers ✤ http: load balancers ✤ web: html e loosely coupling ✤ tls: https
- 15. HTTP faz isso tudo mesmo? Me mostre um Exemplo
- 16. Web O Sistema Escalável
- 17. Protocolos da Internet veronica: busca em gopher smtp: email irc: chat 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
- 18. E hoje? smtp: email bittorrent: arquivos irc, im: chat ssh: acesso remoto
- 19. home banking: www compras: www calendário: www email: www chat: www documentos: www conteúdo restrito: www sexo: www
- 20. 2000 - Roy Fielding why the web? why? Do REST Ao RESTful Www.caelum.com.br
- 21. REpresentational State Transfer O que é isso?
- 22. Recursos É algo interessante para sua aplicação. Fotos, relatorios, arquivos, Lista de buracos da BR 101. Tudo é um recurso.
- 23. 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
- 24. 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>
- 25. 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>
- 26. Interface Uniforme Mantendo as coisas simples
- 28. Interface Uniforme Agora o foco são os Recursos.
- 29. 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
- 30. 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
- 31. 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
- 32. Representações Atom
- 33. Escolhendo uma Representação GET /pedidos/2009/11 HTTP 1.1 HOST exemplo.com Accept: application/xml 200 OK <pedido … />
- 34. 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>
- 35. Falta de Estado Http é Stateless
- 36. Falta de Estado Basicamente significa não utilizar sessões HTTP. Sem sessões, favorecemos a escalabilidade. Os clientes precisam aprender a viver sem sessões.
- 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. Escalabilidade Falta de estado pode ser bom.
- 44. Escalabilidade Falta de estado pode ser bom.
- 45. A solução REST para Java JSR-311 - JAX-RS
- 46. JAX-RS - Definindo um Recurso @Path("/pedido/{id}") public class PedidoResource { @GET @Produces( { MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON }) public Pedido getPedidoById(@PathParam("id") Long id){ PedidoDAO pedidoDAO = new PedidoDAO(); Pedido pedido = pedidoDAO.getPedidoById(id); return pedido; } }
- 47. JAX-RS + JAX-B Serialização Simples do Modelo @XmlRootElement public class Pedido { private Long id; private Double total; private Calendar dataCriacao; private enum status; //Getters e Setters... }
- 48. A vida de um recurso Nao é apenas CRUD
- 49. Recebi meu recurso. Mas e agora, o que eu posso fazer com ele? Que ações estão disponiveis para meu recurso? Com que outros recursos eu posso interagir?
- 50. Recebi meu recurso. Mas e agora, o que eu posso fazer com ele? Que ações estão disponiveis para meu recurso? Com que outros recursos eu posso interagir? Template URI’s podem ajudar?
- 51. Os possíveis estados de um Pedido
- 52. O Recurso pode trazer link’s para as proximas transições Os Recursos agora trazem consigo: • Dados • Linkʼs para outros recursos (transições de estado) Exemplo: <?xml version="1.0" encoding="UTF-8"?> <pedido> <dataCriacao>2009-11-23T00:15:15Z</dataCriacao> <id>1</id> <total>137.00</total> <status>unpaid</status> <atom:link rel="cancel href="http://localhost:3000/pedido/3"/> <atom:link rel="pay" ref="http://localhost:3000/pagamento/pedido/3"/> </pedido>
- 53. O Recurso pode trazer link’s para as proximas transições Os Recursos agora trazem consigo: • Dados é a! to di • Linkʼs para outros recursos (transições de estado) Is Exemplo: m e e r <?xml version="1.0" encoding="UTF-8"?> <pedido> p <id>1</id> H y <dataCriacao>2009-11-23T00:15:15Z</dataCriacao> <total>137.00</total> <status>unpaid</status> <atom:link rel="cancel href="http://localhost:3000/pedido/3"/> <atom:link rel="pay" ref="http://localhost:3000/pagamento/pedido/3"/> </pedido>
- 54. Hypermedia com JAX-RS Quebrou a firma.
- 55. Hypermedia com JAX-RS? Precisamos de um Assembler de Recursos public class PedidoXMLAssembler { private final String LINK_BASE = "<atom:link rel="%s" href="%s"/>"; public String pedidoToXmlAtom(Pedido pedido, UriInfo uriInfo) throws JAXBException { JAXBContext context = JAXBContext.newInstance(Pedido.class); Marshaller marshaller = context.createMarshaller(); StringWriter out = new StringWriter(); marshaller.marshal(pedido, out); int idx = out.getBuffer().indexOf("</pedido>"); StringBuilder links = getAtomLinks(pedido, uriInfo); out.getBuffer().insert(idx, links.toString()); return out.toString(); } private StringBuilder getAtomLinks(Pedido pedido, UriInfo uriInfo) { StringBuilder builder = new StringBuilder(); if (pedido.getStatus() == PedidoStatus.NOVO) { builder.append(String.format(LINK_BASE, "cancel", uriInfo .getBaseUriBuilder().path("/pedido/" + pedido.getId()) .build())); builder.append(String.format(LINK_BASE, "pay", uriInfo .getBaseUriBuilder().path( "/pagamento/pedido/" + pedido.getId()).build())); } return builder; }
- 56. Hypermedia As The Engine Of Application State HATEOAS
- 57. HATEOAS - Hypermedia As The Engine Of Application State • Os linkʼs informam os próximos passos válidos • Seguindo estes linkʼs interagimos com os recursos • E assim mudamos o estado da aplicação Após um entry point basta seguir os links Hypermedia descreve o protocolo
- 58. http://restfulie.caelum.com.br/ Framework para HATEOAS Java, Ruby, c#
- 59. Client - Java Order order = new Order(); // place the order order = service("http://www.caelum.com.br/order").post(order); // cancels it resource(order).getTransition("cancel").execute();
- 60. Server - Java public class Order implements StateResource { public List<Transition> getFollowingTransitions(Restfulie control) { if (status.equals("unpaid")) { control.transition("latest"). uses(OrderingController.class).get(this); control.transition("cancel"). uses(OrderingController.class).cancel(this); } return control.getTransitions(); } }
- 61. Client - Ruby # retrieves the resource through GET: the entry point order = Order.from_web resource_uri puts "Order price is #{order.price}" # sends a post request to create a payment order.pay payment # sends a delete request order.cancel
- 62. Server - Ruby class Order < ActiveRecord::Base acts_as_restfulie do |transitions| transitions << [:show] transitions << [:destroy] if can_cancel? transitions << [:controller => :payments, :action => :create, {:id => id}] if can_pay? end end
- 63. Obrigado. Luiz Costa luiz.costa@caelum.com.br @gutomcosta Sergio Junior sergio.junior@caelum.com.br @sergioazevedo
Notes de l'éditeur
- Luiz e Sergio : Bom dia, nos somos Luiz e Sergio Luiz O objetivo de nossa apresenta&#xE7;&#xE3;o &#xE9; mostrar REST como uma alternativa a implementa&#xE7;&#xE3;o de Web Services tradicionais. Sergio: Vamos falar um pouco da teoria e depois mostrar um demo de uma aplica&#xE7;&#xE3;o aplicando essa teoria.
- Bom, pra come&#xE7;ar, vamos contar uma hist&#xF3;ria que j&#xE1; aconteceu com a gente em uma empresa. Ou melhor, com amigos nossos. Rs Se algu&#xE9;m notar alguma semelharn&#xE7;a com a realidade &#xE9; mera coicid&#xEA;ncia. Um dos maiores problemas que temos hoje em dia, &#xE9; o de integrar 2 ou mais aplica&#xE7;&#xF5;es n&#xE9;. Como fazer para compartilhar informa&#xE7;&#xF5;es entre estas informa&#xE7;&#xF5;es. Em uma empresa qualquer, passamos por um problema desses. O que &#xE9; bem comum hoje em dia. T&#xED;nhamos v&#xE1;rias aplica&#xE7;&#xF5;es dentro da empresa e estas precisavam se comunicar. Trocar informa&#xE7;l&#xF5;es. T&#xED;nhamos a&#xED; o velho problema. Como integrar isso. A primeira solu&#xE7;&#xE3;o que foi utilizado &#xE9;:
- Banco de dados Vamos compartilhar as Tabelas que s&#xE3;o comuns para as aplica&#xE7;&#xF5;es e t&#xE1; tudo certo. Ent&#xE3;o as aplica&#xE7;&#xF5;es que utilizavam as tabelas de clientes, produtos, iriam acessar a mesma tabela. Isso durante um tempo funcionou bem. S&#xF3; que as coisas come&#xE7;aram a ficar mais complicadas. V&#xE1;rias outras aplica&#xE7;&#xF5;es foram aparecendo, precisam de acessar informa&#xE7;&#xF5;es de clientes e produtos, ou at&#xE9; mesmo de outras tabelas. Isso come&#xE7;ou a gerar um trabalho enorme, manter todas estas tabelas em um estado consistente. Isso era trabalhoso mas de certa forma funcionava. At&#xE9; o dia que apreceu um parceiro externo. N&#xF3;s precis&#xE1;vamos trocar informa&#xE7;&#xF5;es com um parceiro. Como fazer? Algu&#xE9;m deu a solu&#xE7;&#xE3;o, a gente pede pra ele uma tabela, o ip do servidor de banco de dados e constru&#xED;mos a url de conex&#xE3;o e fazemos a conex&#xE3;o direta neste servidor. Brilhante n&#xE9;? &#xC9; evidente que este parceiro n&#xE3;o aceito esta solu&#xE7;&#xE3;o, n&#xE3;o iria liberar acesso ao servidor de banco de dados deles. Enfim n&#xE3;o deu muito certo. O pessoal mais antigo ent&#xE3;o disse. Vamos fazer troca de arquivos. Isso era muito comum antigamente.
- O pessoal mais antigo ent&#xE3;o disse. Vamos fazer troca de arquivos. Isso era muito comum antigamente. Os 2 parceiros v&#xE3;o combinar alguma coisa sobre como estes arquivos ser&#xE3;o formados e ent&#xE3;o, n&#xF3;s constru&#xED;mos o nosso parser e conseguimos ler os dados destes arquivos. Muito legal n&#xE9;. Mas e se aparecer um outro parceiro externo? Hoje em dia, n&#xE3;o podemos pensar que nossa aplica&#xE7;&#xE3;o &#xE9; uma ilha, onde somente a gente vai utilizar seus dados. Todo mundo quer trocar informa&#xE7;&#xE3;o hoje em dia, se vc for observar, quase tudo &#xE9; integrado, o servi&#xE7;o de cart&#xE3;o de cr&#xE9;dito, a compra de passagens, em uma aplica&#xE7;&#xE3;o de agencia de viagens etc. Come&#xE7;aram a surgir v&#xE1;rias op&#xE7;&#xF5;es no mercado, apareceram os famos Objetos Distribu&#xED;dos, com aquele neg&#xF3;cio do CORBA. Era interessante n&#xE9;, eles tinham um discurso que ia resolver estes problemas de integra&#xE7;&#xE3;o com objetos distribu&#xED;dos. Esse neg&#xF3;cio n&#xE3;o vingou n&#xE9;. Precisavamos de algo mais padronizado. Voltando ao ao problema
- Podemos utilizar web services. Todo mundo hoje utiliza web service. &#xC9; a forma mais comum de se fazer integra&#xE7;&#xE3;o hoje. J&#xE1; temos um formato padronizado, podemos tirar proveito da interoperabilidade, enfim, v&#xE1;rias vantagens n&#xE9;.; Vamos d&#xE1; uma olhada em como eles funcionam.
- Os Ws s&#xE3;o padronizados, tem uma tal de WS* que define um conjun to de padr&#xF5;es Outro coisa interessante, &#xE9; que agora vc n&#xE3;o fica trocando arquivos, vc sabe exatamente o que fazer. Ou seja, vc tem disponivel em algum lugar, algo que te diz Como utilizar este servi&#xE7;o. Isso &#xE9; oq conhecemos como WSDL. Para vc utilizar o servi&#xE7;o, vc precisa conhecers seu descritor. Vc tem um contrato. Como vcs podem perceber, estes web services s&#xE3;o focados em opera&#xE7;&#xF5;es. Vc tem que conhecer quais s&#xE3;o as opera&#xE7;&#xF5;es que vc pode executar sobre o servi&#xE7;o. Isso at&#xE9; parece razoavel n&#xE9;, eu preciso saber oq eu possa fazer para interagir com o servi&#xE7;o.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- Vamos d&#xE1; uma olhada em algo que j&#xE1; faz parte da nossa vida hoje. A Web. Quando vc quer saber de alguma noticia o que vc faz hoje? Liga a TV? Ser&#xE1; que est&#xE1; passando o notic&#xE1;rio? Vc utiliza a internet.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- REST significa &#x2013; REpresentational State Transfer Pontos Chave: &#xC9; um estilo de arquitetura e &#xC9; baseado em um conjunto de principios Bom para aproveitar ent&#xE3;o todas as caracter&#xED;sticas da web , o que precisamos em primeiro lugar &#xE9; tentar ser simples, da mesma forma que a web &#xE9;. Isto significa que n&#xE3;o precisamos de nada al&#xE9;m do que j&#xE1; est&#xE1; dispon&#xED;vel na web para implementar aplica&#xE7;&#xF5;es que fazem parte da web. REST &#xE9; simples, mas n&#xE3;o &#xE9; pq ele simples que s&#xF3; &#xE9; poss&#xED;vel implementar servi&#xE7;os simples. Podemos ver o Rest como um conjunto de princ&#xED;pios que definem como os Web Standards , tal como HTTP, URIs s&#xE3;o utilizados. A id&#xE9;ia ent&#xE3;o &#xE9; que se vc adota estes princ&#xED;p&#xED;os enquanto projeta sua aplica&#xE7;&#xE3;o, esta ir&#xE1; conseguir explorar todos os benef&#xED;cios que a arquitetura web nos tr&#xE1;s. Vamos come&#xE7;ar a analisar estes princ&#xED;pios
- Diferente da vis&#xE3;o tradicional de web services, o que vc exp&#xF5;e em rest s&#xE3;o Recursos. Mas o que s&#xE3;o estes Recursos? Recursos s&#xE3;o coisas importantes que vc tem na sua aplica&#xE7;&#xE3;o. Eles podem ser algo f&#xED;sico como uma foto, ou um conceito abstrato como &#x201C;Como est&#xE1; o tempo agora?&#x201D;. Ent&#xE3;o fotos, relatorios, arquivos e at&#xE9; uma lista de buracos da br 101, podem ser recursos. Inclusive o resultado de um c&#xE1;lculo. Por exemplo, posso ter um recurso Total de Vendas por Regi&#xE3;o. Isso &#xE9; um recurso algor&#xED;tmico. Vale destacar que um recurso identifica alguma coisa. Eu posso ter o recurso Todos os Clientes, mas eu tamb&#xE9;m tenho o Recurso Cliente &#x201C;Jos&#xE9; Maria&#x201D; O primeiro, representa todos os clientes, o segundo apenas o jos&#xE9; maria. Tudo o que vc vai expor em sua aplica&#xE7;&#xE3;o utilizando REST vai se transformar em Recursos.
- Ent&#xE3;o agora a gente sabe que expomos recursos. Ent&#xE3;o na minha aplica&#xE7;&#xF5;e eu tenho v&#xE1;rios recursos dispon&#xED;veis para utiliza&#xE7;&#xE3;o em outras aplica&#xE7;&#xF5;es. Mas como eu utilizo estes recursos? Vamos pensar como &#xE9; feito nos webServices tradicionais. Vc tem um EndPoint onde vc descobre um WSDL que te d&#xE1; as informa&#xE7;&#xF5;es do Servi&#xE7;o. Tem que ter algo para que eu consiga Identificar os recursos que eu tenho na minha apliuca&#xE7;&#xE3;o. Precisamos de um ID. Um identificador. Por exemplo para um recurso Cliente eu poderia utilizar o CPF como um identificador. Acontece que queremos que nossa aplica&#xE7;&#xE3;o fa&#xE7;a parte da web, e h&#xE1; um concenso na web sobre IDs. A forma padr&#xE3;o de identificar qualquer coisa na web &#xE9; atrav&#xE9;s de URIs. Ent&#xE3;o para eu acessar os recursos eu vou utilizar URIs, da mesma forma que eu fa&#xE7;o para acessar o site do google. Se eu estou desenvolvendo uma aplica&#xE7;&#xE3;o para cuidade de clientes eu posso expor alguns recursos: &#x201C;Todos os clientes&#x201D; este vai ser acessado por http://exemplo.com/clientes. Repare que este recurso, representa todos os clientes da minha aplica&#xE7;&#xE3;o. Eu n&#xE3;o estou me referindo a um cliente em espec&#xED;fico. Se eu quiser fazer isso, ent&#xE3;o tenho que expor outro recurso. http://exemplo.com/clientes/10 Repare que agora eu acesso apenas o cliente 10. ou http://exemplo.com/clientes/23 Somente o cliente 23. Como utilizamos uris para identificar recursos &#xE9; comum ver por a&#xED;, uris bem leg&#xED;veis para facilitar sua leitura. Agora, como este recurso &#xE9; identific&#xE1;vel, vc pode chegar no Browser e digitar esta URI e ir diretamente at&#xE9; este recurso, ou at&#xE9; mesmo, copiar esta URI e colar em um e-mail e enviar para o setor de marketing oferecer uma promocao a este cliente. &#xC9; assim que a web funciona n&#xE9;. Vc sabe as uris dos sites que vc acessa.
- Uma vez que conseguimos encontrar um recurso e solicitar informa&#xE7;&#xF5;es sobre ele, &#xE9; poss&#xED;vel que estas informa&#xE7;&#xF5;es possam nos levar outros recursos.Ex:Quando solicitamos &#x201C;Cliente n&#xFA;mero 23" podemos ter as informa&#xE7;&#xF5;es do recurso cliente 23 e alem disso, alguns pedidos podem estar associados a este cliente. Ent&#xE3;o como poder&#xED;amos representar isso? N&#xF3;s vamos falar de representa&#xE7;&#xF5;es com mais detalhes um pouco a frente, mas por enquanto vamos pensar nestes pontos: a) Poder&#xED;amos ter uma representa&#xE7;&#xE3;o do recurso cliente em XML e inclu&#xED;r os dados dos pedido junto desta representa&#xE7;&#xE3;o
- b) Poder&#xED;amos ter uma representa&#xE7;&#xE3;o do recurso cliente em XML e incluir um Link para o recurso Pedido.Se observamos a Web trabalha atraves de links. Quando vc entra em um site na web, normalmente vc n&#xE3;o continua sua navega&#xE7;&#xE3;o digitando novos endere&#xE7;os na barra do se browser. O que vc faz &#xE9; seguir os links. Se nossa aplica&#xE7;&#xE3;o quer fazer parte da web, temos que incorparar estas caracter&#xED;sticas nela.Assim n&#xF3;s utilizamos links para continuar a nevaga&#xE7;&#xE3;o pela nossa aplica&#xE7;&#xE3;o, da mesma forma que a web. Esse &#xE9; o conceito conhecido como Hipermedia: os documentos n&#xE3;o s&#xE3;o apenas dados, mas links para outros recursos.
- Bom, falamos de URIs e Recursos, e por &#xFA;ltimo falamos de Links. Como podemos utilizar estas URIs e Links em nossa aplica&#xE7;&#xE3;o?Quando vc v&#xEA; uma URI em alguma propaganda em um Outdoor, ou at&#xE9; mesmo algu&#xE9;m informando isso em um programa de televis&#xE3;o, vc pode pegar esta URI, digitar no seu Browser e esperar um resposta. Mas o que seu Browser faz com esta URI? Como ele sabe o que fazer com ela?O browser sabe o que fazer com esta URI, pq existe uma interface padr&#xE3;o para todo recurso. O seja, todo recurso suporta a mesmo conjunto de instrucoes, ou o mesmo conjunto de opera&#xE7;&#xF5;es. Em toda Web, existem apenas algumas coisas b&#xE1;sicas que vc pode fazer com recursos. O protocolo HTTP nos fornece quatro m&#xE9;todos b&#xE1;sicos para opera&#xE7;&#xF5;es mais comuns. Ele chama estes m&#xE9;todos de verbos, s&#xE3;o eles (GET, POST,PUT,DELETE ) e alem deles temos (HEAD e OPTIONS). Isto significa que estes m&#xE9;todos est&#xE3;o definidos na especifica&#xE7;&#xE3;o do protocolo HTTP.&#xC9; como se imagin&#xE1;ssemos (em OO) que existe uma interface que todo recurso precisasse estender.
- Como temos uma interface padr&#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&#xE7;&#xE3;o de um recurso usando um m&#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&#xE9;todo GET est&#xE1; definida na especifica&#xE7;&#xE3;o do HTTP.Ent&#xE3;o o que o meu Browser faz quando eu digito uma URI &#xE9; enviar um solicita&#xE7;&#xE3;o usando o m&#xE9;todo GET do HTTP. Mas pera a&#xED;. Eu tenho 4 m&#xE9;todos dispon&#xED;veis para realizar todas as opera&#xE7;&#xF5;es em um recurso? Esse neg&#xF3;cio t&#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um "Servi&#xE7;o" web hoje. Temos um "Servi&#xE7;o" e v&#xE1;rios m&#xE9;todos que atuam sobre este servi&#xE7;o.&#xA0; Se quisermos utilizar este servi&#xE7;o precisamos conhecer antes a sua interface. N&#xE3;o tem como utilizaramos sem conhecer esta interface. Utilizando Rest n&#xF3;s utilizamos uma forma mais gen&#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&#xE3;o? Ent&#xE3;o n&#xF3;s precisamos utilizar somente os m&#xE9;todos do HTTP. Mas como resolver tudo com estes m&#xE9;todos? Talvez va&#xE3;o existir situa&#xE7;&#xF5;es que n&#xE3;o vamos conseguir resolver com apenas estes m&#xE9;todos. A resposta para isto &#xE9;, vamos criar v&#xE1;rios recursos.Na implementa&#xE7;&#xE3;o tradicional temos apenas um 1 servi&#xE7;o que tem v&#xE1;rios m&#xE9;todos. Na nossa implementa&#xE7;&#xE3;o baseada em rest, vamos ter v&#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&#xE9;todos default do http.
- representa um pedido em especifico, o template {identificador} informa que ser&#xE1; utilizado algo que identifique um pedido em especifico, pode ser um n&#xFA;mero.As opera&#xE7;&#xF5;es s&#xE3;o: Agora n&#xF3;s utilizamos os m&#xE9;todos da interface padr&#xE3;o sobre os recursos criados. O m&#xE9;todo GET sobre um pedido especifico tem o mesmo efeito que o metodo obterDetalhesDeUmPedido().Com uma abordagem como essa,existe um n&#xFA;mero fixo de opera&#xE7;&#xF5;es, mas podemos representar milh&#xF5;es de pedidos diferentes atrav&#xE9;s de recursos. Ent&#xE3;o quando eu quero obter a informa&#xE7;&#xE3;o de um recurso eu utilizo o m&#xE9;todo GET. Quando vc faz uma requisi&#xE7;&#xE3;o GET em um recurso vc n&#xE3;o est&#xE1; fazendo qualquer altera&#xE7;&#xE3;o no estado do Servidor. Qualquer quantidade de requisi&#xE7;&#xF5;es GET que eu fizer no mesmo recurso, ter&#xE1; sempre o mesmo efeito. Ent&#xE3;o uma opera&#xE7;&#xE3;o GET &#xE9; segura, n&#xE3;o h&#xE1; mudan&#xE7;as de estado. Para criar um pedido utilizamos o POST ou o PUT. A diferen&#xE7;a &#xE9; que com o POST o servidor decide qual URI vamos utilizar. Por exemplo, se utilizar uma URI deste modo: http://exemplo.com/pedidos/1258, onde o n&#xFA;mero &#xE9; um ID que s&#xF3; ser&#xE1; conhecido ap&#xF3;s a cria&#xE7;&#xE3;o do recurso, utilizamos post. Se queremos criar um recuro j&#xE1; com uma URI definida, ent&#xE3;o utilizamos o PUT> E para excluir um recurso utilzamos o DELETE Todas estas itera&#xE7;&#xF5;es podem ter problemas, e para utilizamos o c&#xF3;digo de erro do HTTP. O clietne deve verificar estes codigos de erro da requisi&#xE7;&#xE3;o para saber se deu tudo certo ou n&#xE3;o. E a partir da&#xED;, qualquer aplica&#xE7;&#xE3;o que saiba conversar com o HTTP pode utilizar nossos Recursos. Inclusive seu Browser!!!
- representa todos os pedidos, ou seja toda a cole&#xE7;&#xE3;o de pedidos dispon&#xED;veis.Podemos descrever o que as opera&#xE7;&#xF5;es padr&#xE3;o fazem para este recurso como:
- Um recurso &#xE9; apenas uma id&#xE9;ia, algo conceitual. Quando utilizamos uma URI para chegar at&#xE9; um recurso, estamos na verdade pedindo o servidor web exatamente o qu&#xEA;? O Servidor web n&#xE3;o pode nos enviar uma id&#xE9;ia. O que um servidor sabe responder para n&#xF3;s, &#xE9; apenas um conjunto de bytes. Este bytes normalmente, deve estar em formato espec&#xED;fico, em uma linguagem espec&#xED;fica. Esta linguagem e este formato &#xF3; que chamos de representa&#xE7;&#xE3;o de um recurso.Um mesmo recurso, pode ter diversas representa&#xE7;&#xF5;es. Por exemplo, eu posso querer exibir os dados do meu Recurso Cliente em um Browser, para isso eu podeira utilizar uma representa&#xE7;&#xE3;o deste recurso em XHTML. Ou ent&#xE3;o eu poderia disponibilizar os dados deste recurso para uma outra aplica&#xE7;&#xE3;o. Para isso eu poderia utilizar XML. O fato &#xE9; que podem haver v&#xE1;rias representa&#xE7;&#xF5;es para um mesmo recurso. Aqui tem os algumas delas.
- Um mesmo recurso, pode ter diversas representa&#xE7;&#xF5;es. E quando solicitamos informa&#xE7;&#xF5;es sobre um recurso atrav&#xE9;s da chamada de m&#xE9;todos padr&#xE3;o, n&#xF3;s tamb&#xE9;m podemos informar, qual &#xE9; a representa&#xE7;&#xE3;o que esperamos. N&#xF3;s temos um recurso que &#xE9;: "/pedidos/2009/11" (pedidos de novembro de 2009). Ele pode ser acessado por uma URI: http://exemplo.com/pedidos/2009/11.Quando acessamos esta URI atrav&#xE9;s de um browser, o que esperamos como resposta? Uma p&#xE1;gina web contendo os dados dos pedidos de novembro de 2009. J&#xE1; quando acessamos por uma aplica&#xE7;&#xE3;o, talvez fosse melhor, receber estes dados em uma outra representa&#xE7;&#xE3;o ou formato, por exemplo XML, ou at&#xE9; mesmo em um arquivo texto separado por v&#xED;rgulas. Se vc fornece os formatos xHTML e XML para representa&#xE7;&#xF5;es do seu recurso, ele pode ser consumido n&#xE3;o somente pela sua aplica&#xE7;&#xE3;o, mas por qualquer Web Brower ou seja, as informa&#xE7;&#xF5;es de sua aplica&#xE7;&#xE3;o podem estar dispon&#xED;vel para todos que saibam utilizar a web.
- Como eu disse, seu que quiser exibir os dados do meu recurso em um site por exemplo, eu posso utilizar um representa&#xE7;&#xE3;o em XHTML. Agora se for para uma outra aplica&#xE7;&#xE3;o utilizar vamos expor os dados em xml. Aqui alguns exemplos de como isso poderia ser utilizado.
- O &#xFA;ltimo princ&#xED;pio que n&#xF3;s gostar&#xED;amos de falar &#xE9; sobre falta de estado. A falta de estado significa que toda a solicita&#xE7;&#xE3;o HTTP ocorre em um isolamento completo. Quando o cliente faz uma solicita&#xE7;&#xE3;o HTTP, inclui todas as informa&#xE7;&#xF5;es necess&#xE1;rias para o servidor processar e responder esta solicita&#xE7;&#xE3;o.O princ&#xED;pio da falta de estado torna as coisas muito mais simples. Um cliente pode fazer solicita&#xE7;&#xF5;es para um mesmo recurso, diversas vezes. Uma servidor pode parar de responder por algum problema t&#xE9;cnico e interromper a solicita&#xE7;&#xE3;o no meio do caminho sem maiores problema, visto que o cliente pode reenviar a novamente.
- Mas &#xE9; evidente que precisamos armazenar os dados de nosso Recurso, pois s&#xE3;o estes dados que nos fazem querer utiliz&#xE1;-lo. A falta de estado que estamos falando aqui &#xE9; a falta de estado da aplica&#xE7;&#xE3;o. Existe uma diferen&#xE7;a entre falta de estado da aplica&#xE7;&#xE3;o e falta de estado do recurso. A falta de estado da aplica&#xE7;&#xE3;o significa que o cliente &#xE9; quem deve ser o respons&#xE1;vel por gerenciar seu pr&#xF3;prio caminho&#xA0; pela aplica&#xE7;&#xE3;o. O servidor nem sabe que existe um cliente conectado. Agora o estado do recurso &#xE9; o mesmo para todo o cliente e seu lugar &#xE9; no servidor. Por exemplo, quando voc&#xEA; faz um upload de fotos no Flickr ele cria um novo recurso que tem sua pr&#xF3;pria URI e pode ser destino de futuras solicita&#xE7;&#xF5;es. Esta foto &#xE9; parte do estado do Recurso e ficar&#xE1; no servidor at&#xE9; que algum cliente a apague.
- A falta de estado na apliaca&#xE7;&#xE3;o nos traz uma vantagem enorme quando falamos em escalabilidade. Imagine que eu tenho um servidor atendendo uma aplica&#xE7;&#xE3;o. Tem um cliente acessando, e o servidor respondendo. De repente come&#xE7;am a aparecer outros clientes acessando sua aplica&#xE7;&#xE3;o. Ela come&#xE7;a a se tornar popular, o n&#xFA;mero de requisi&#xE7;&#xF5;es vai aumentando. At&#xE9; que chega um ponto que seu servidor abre o bico. E a&#xED; o que fazer?
- A falta de estado na apliaca&#xE7;&#xE3;o nos traz uma vantagem enorme quando falamos em escalabilidade. Imagine que eu tenho um servidor atendendo uma aplica&#xE7;&#xE3;o. Tem um cliente acessando, e o servidor respondendo. De repente come&#xE7;am a aparecer outros clientes acessando sua aplica&#xE7;&#xE3;o. Ela come&#xE7;a a se tornar popular, o n&#xFA;mero de requisi&#xE7;&#xF5;es vai aumentando. At&#xE9; que chega um ponto que seu servidor abre o bico. E a&#xED; o que fazer?
- A falta de estado na apliaca&#xE7;&#xE3;o nos traz uma vantagem enorme quando falamos em escalabilidade. Imagine que eu tenho um servidor atendendo uma aplica&#xE7;&#xE3;o. Tem um cliente acessando, e o servidor respondendo. De repente come&#xE7;am a aparecer outros clientes acessando sua aplica&#xE7;&#xE3;o. Ela come&#xE7;a a se tornar popular, o n&#xFA;mero de requisi&#xE7;&#xF5;es vai aumentando. At&#xE9; que chega um ponto que seu servidor abre o bico. E a&#xED; o que fazer?
- A falta de estado na apliaca&#xE7;&#xE3;o nos traz uma vantagem enorme quando falamos em escalabilidade. Imagine que eu tenho um servidor atendendo uma aplica&#xE7;&#xE3;o. Tem um cliente acessando, e o servidor respondendo. De repente come&#xE7;am a aparecer outros clientes acessando sua aplica&#xE7;&#xE3;o. Ela come&#xE7;a a se tornar popular, o n&#xFA;mero de requisi&#xE7;&#xF5;es vai aumentando. At&#xE9; que chega um ponto que seu servidor abre o bico. E a&#xED; o que fazer?
- Podemos escalar a vontade os servidores web. At&#xE9; que o problema mude de lugar. (BD)
- Podemos escalar a vontade os servidores web. At&#xE9; que o problema mude de lugar. (BD)
- Bom, pra come&#xE7;ar, vamos contar uma hist&#xF3;ria que j&#xE1; aconteceu com a gente em uma empresa. Ou melhor, com amigos nossos. Rs Se algu&#xE9;m notar alguma semelharn&#xE7;a com a realidade &#xE9; mera coicid&#xEA;ncia. Um dos maiores problemas que temos hoje em dia, &#xE9; o de integrar 2 ou mais aplica&#xE7;&#xF5;es n&#xE9;. Como fazer para compartilhar informa&#xE7;&#xF5;es entre estas informa&#xE7;&#xF5;es. Em uma empresa qualquer, passamos por um problema desses. O que &#xE9; bem comum hoje em dia. T&#xED;nhamos v&#xE1;rias aplica&#xE7;&#xF5;es dentro da empresa e estas precisavam se comunicar. Trocar informa&#xE7;l&#xF5;es. T&#xED;nhamos a&#xED; o velho problema. Como integrar isso. A primeira solu&#xE7;&#xE3;o que foi utilizado &#xE9;: