O documento discute a arquitetura REST e como implementá-la de forma RESTful. Ele explica os principais conceitos como recursos, identidade, interface uniforme e hipermídia. Também discute como implementar REST em Java usando JAX-RS e como frameworks como o Restfulie podem facilitar a criação de aplicações HATEOAS.
Como um verdadeiro sistema REST funciona: arquitetura e performance na AbrilLuis Cipriani
A palestra irá compartilhar a experiência e lições aprendidas no desenvolvimento da plataforma de publicação da Abril, um sistema distribuído com vários nós independentes que se comunicam usando REST e hypermidia. Também introduziremos alguns conceitos avançados de HTTP que podem fazer com que sistemas REST executem com melhor performance, evitando os problemas comuns de se manter uma plataforma em larga escala, com uma grande diversidade de usuários.
Palestra dada por mim (Felipe Ribeiro) no CONAPHP 2008 - Congresso Nacional de PHP que ocorreu em São Paulo nos dias 18 e 19 de Outubro dentro do CONISLI 2008
Como um verdadeiro sistema REST funciona: arquitetura e performance na AbrilLuis Cipriani
A palestra irá compartilhar a experiência e lições aprendidas no desenvolvimento da plataforma de publicação da Abril, um sistema distribuído com vários nós independentes que se comunicam usando REST e hypermidia. Também introduziremos alguns conceitos avançados de HTTP que podem fazer com que sistemas REST executem com melhor performance, evitando os problemas comuns de se manter uma plataforma em larga escala, com uma grande diversidade de usuários.
Palestra dada por mim (Felipe Ribeiro) no CONAPHP 2008 - Congresso Nacional de PHP que ocorreu em São Paulo nos dias 18 e 19 de Outubro dentro do CONISLI 2008
Navegando em um mar de siglas do mundo javaAndrei Tognolo
O números de apis e frameworks que existem para a plataforma Java podem assustar novos desenvolvedores. Essa palestra busca mostrar uma visão geral das principais apis relacionadas ao padrão JavaEE.
Após visitar as principais tecnologias JavaEE, vamos analisar cenários e decidir quais tecnologias utilizar.
Slides do curso técnico de informática do IFPE - Campus Garanhuns. Disciplina de linguagens de programação para a web. Apresenta uma introdução sobre o desenvolvimento para esta área e introduz o HTML.
Curso sobre AngularJS, tratando deste ambiente e ferramentas modernas de desenvolvimento até o desenvolvimento de uma aplicação usando AngularJS. Curso em duas partes.
No final foram desenvolvidas duas aplicações que podem ser vistas nos links:
https://github.com/alvarowolfx/shopping-list
https://github.com/alvarowolfx/ng-pokedex
Aqui são apresentados conceitos básicos sobre o paradigma web. Simples e rápido.
/**Depois que entrei no mundo Java, começei a procurar por conteúdo na internet para estudar, então me deparei com um ótimo site, http://www.argonavis.com.br, de um grande cara chamado Helder Rocha, que disponibiliza este mesmo conteúdo em seu site também. Obrigado pela ajuda a comunidade.*/
O crescimento do mercado mobile e a necessidade de prover acesso a serviços existentes para desenvolvedores terceiros popularizaram o uso e disponibilização de APIs REST públicas. Com isso, pontos como escalabilidade, versionamento, desacoplamento e encapsulamento tornaram-se centrais no projeto de APIs. Nesta palestra será apresentado o conceito de APIs Hypermedia e como seu uso ajuda no projeto e implementação de APIs mais flexíveis.
Navegando em um mar de siglas do mundo javaAndrei Tognolo
O números de apis e frameworks que existem para a plataforma Java podem assustar novos desenvolvedores. Essa palestra busca mostrar uma visão geral das principais apis relacionadas ao padrão JavaEE.
Após visitar as principais tecnologias JavaEE, vamos analisar cenários e decidir quais tecnologias utilizar.
Slides do curso técnico de informática do IFPE - Campus Garanhuns. Disciplina de linguagens de programação para a web. Apresenta uma introdução sobre o desenvolvimento para esta área e introduz o HTML.
Curso sobre AngularJS, tratando deste ambiente e ferramentas modernas de desenvolvimento até o desenvolvimento de uma aplicação usando AngularJS. Curso em duas partes.
No final foram desenvolvidas duas aplicações que podem ser vistas nos links:
https://github.com/alvarowolfx/shopping-list
https://github.com/alvarowolfx/ng-pokedex
Aqui são apresentados conceitos básicos sobre o paradigma web. Simples e rápido.
/**Depois que entrei no mundo Java, começei a procurar por conteúdo na internet para estudar, então me deparei com um ótimo site, http://www.argonavis.com.br, de um grande cara chamado Helder Rocha, que disponibiliza este mesmo conteúdo em seu site também. Obrigado pela ajuda a comunidade.*/
O crescimento do mercado mobile e a necessidade de prover acesso a serviços existentes para desenvolvedores terceiros popularizaram o uso e disponibilização de APIs REST públicas. Com isso, pontos como escalabilidade, versionamento, desacoplamento e encapsulamento tornaram-se centrais no projeto de APIs. Nesta palestra será apresentado o conceito de APIs Hypermedia e como seu uso ajuda no projeto e implementação de APIs mais flexíveis.
O AngularJS tem atraído muita atenção dos desenvolvedores, e a maioria das aplicações utilizando esse framework open source necessitam se comunicar por meio de APIs web. A plataforma Java EE, com sua robustez e suporte avançado a REST, é uma das melhoras soluções atuais para suportar todos os requisitos de uma API REST de backend para aplicações baseadas em HTML5 e AngularJS.
Esta palestra abordará como construir uma aplicação em AngularJS utilizando tecnologias backend Java EE, incluindo JAX-RS, WebSockets, JSON-P e CDI. Ao final você vai entender os benefícios do uso destas tecnologias, bem como padrões e boas práticas aplicadas nesse modelo de desenvolvimento. Os tópicos abordados incluem JavaScript, HTML5, AngularJS e várias APIs do Java EE.
O AngularJS tem atraído muita atenção dos desenvolvedores, e a maioria das aplicações utilizando esse framework open source necessitam se comunicar por meio de APIs web. A plataforma Java EE, com sua robustez e suporte avançado a REST, é uma das melhoras soluções atuais para suportar todos os requisitos de uma API REST de backend para aplicações baseadas em HTML5 e AngularJS.
Esta palestra abordará como construir uma aplicação em AngularJS utilizando tecnologias backend Java EE, incluindo JAX-RS, WebSockets, JSON-P e CDI. Ao final você vai entender os benefícios do uso destas tecnologias, bem como padrões e boas práticas aplicadas nesse modelo de desenvolvimento. Os tópicos abordados incluem JavaScript, HTML5, AngularJS e várias APIs do Java EE.
Uma apresentação sobre o protocolo que fornece a base do desenvolvimento sobre a web, suas vantagens, características e más práticas que podem ser evitadas.
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
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
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>
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
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.
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?
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>
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
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
Notas do Editor
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;: