Do REST ao RESTful

                                  Luiz Costa
                       luiz.costa@caelum.com.br
         ...
Integração   O velho problema
O Banco de Dados   Solução Prática #1
Transferência de Arquivos   Solução Prática #2
Web Services   Solução Prática #3
Como são os Web Services hoje?

• Baseados na especificação WS-*

• Descritores WSDL

• SOAP e XML

• Utilizam um estilo RP...
Requisitos não Funcionais
✤   protocolo de transferência de dados amplamente utilizado

✤   escalabilidade

✤   performanc...
Requisitos não Funcionais
✤   http

✤   escalabilidade

✤   performance alta

✤   alta disponibilidade

✤   permitir evolu...
Requisitos não Funcionais
✤   http

✤   web: caches

✤   performance alta

✤   alta disponibilidade

✤   permitir evolução...
Requisitos não Funcionais
✤   http

✤   web: caches

✤   web: proxies, localização geográfica

✤   alta disponibilidade

✤ ...
Requisitos não Funcionais
✤   http

✤   web: caches

✤   web: proxies, localização geográfica

✤   http: load balancers

✤ ...
Requisitos não Funcionais
✤   http

✤   web: caches

✤   web: proxies, localização geográfica

✤   http: load balancers

✤ ...
Requisitos não Funcionais
✤   http

✤   web: caches

✤   web: proxies, localização geográfica

✤   http: load balancers

✤ ...
Requisitos não Funcionais
✤   http

✤   web: caches

✤   web: proxies, localização geográfica

✤   http: load balancers

✤ ...
HTTP faz isso tudo mesmo?



     Me mostre um
        Exemplo
Web   O Sistema Escalável
Protocolos da Internet

         veronica: busca em gopher         smtp: email
   irc: chat
                  wais: busca ...
E hoje?

              smtp: email
          bittorrent: arquivos
              irc, im: chat
          ssh: acesso remoto
home banking: www
    compras: www
   calendário: www
      email: www
       chat: www
  documentos: www
conteúdo restrit...
2000 - Roy Fielding




                      why the web? why?




Do REST Ao RESTful

                                  ...
REpresentational
     State
   Transfer
   O que é isso?
Recursos
É algo interessante para sua
          aplicação.

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

 Tu...
Identidade de um Recurso

Para ser encontrado o recurso precisa ser
              identificado.

 Todos os clientes
 http//...
Link os Recursos
Os dados do pedido junto com o cliente


<cliente>
 <id> 23 </id>
 <nome>Joana Cardoso</nome>
 <cpf>12345...
Link os Recursos
Os recursos devem estar ligados entre sí

<cliente>
 <id>23</id>
 <nome>Joana Cardoso</nome>
 <cpf>123456...
Interface Uniforme   Mantendo as coisas simples
Interface Uniforme
Interface Uniforme




    Agora o foco são os
        Recursos.
Interface Uniforme
Recurso /Pedidos/{Identificador}
http://exemplo.com/pedidos/10
•GET() - obtém os detalhes de um pedido e...
Interface Uniforme
Recurso /Pedidos
http://exemplo.com/pedidos
•GET() - lista todos os pedidos

•PUT() - não é utilizado a...
Mas e se alguma coisa der errado?
Códigos de status do HTTP
•100   –   Continue
•200   –   OK
•201   –   Created
•301   – ...
Representações




            Atom
Escolhendo uma Representação
      GET /pedidos/2009/11 HTTP 1.1
            HOST exemplo.com
          Accept: applicatio...
Possíveis representações do recurso:
        http://exemplo.com/clientes/23
         XHTML                        XML


<h...
Falta de Estado   Http é Stateless
Falta de Estado

Basicamente significa não utilizar sessões HTTP.

Sem sessões, favorecemos a escalabilidade.

Os clientes...
Escalabilidade   Falta de estado pode ser bom.
Escalabilidade   Falta de estado pode ser bom.
Escalabilidade   Falta de estado pode ser bom.
Escalabilidade   Falta de estado pode ser bom.
Escalabilidade   Falta de estado pode ser bom.
Escalabilidade   Falta de estado pode ser bom.
Escalabilidade   Falta de estado pode ser bom.
Escalabilidade   Falta de estado pode ser bom.
A solução REST para Java   JSR-311 - JAX-RS
JAX-RS - Definindo um Recurso
@Path("/pedido/{id}")
public class PedidoResource {

 @GET
 @Produces( { MediaType.APPLICATIO...
JAX-RS + JAX-B
Serialização Simples do Modelo
@XmlRootElement
public class Pedido {

    private Long id;
    private Doub...
A vida de um recurso   Nao é apenas CRUD
Recebi meu recurso.
Mas e agora, o que eu posso fazer com ele?

Que ações estão disponiveis para meu recurso?
Com que outr...
Recebi meu recurso.
Mas e agora, o que eu posso fazer com ele?

Que ações estão disponiveis para meu recurso?
Com que outr...
Os possíveis estados de um Pedido
O Recurso pode trazer link’s
para as proximas transições

Os Recursos agora trazem consigo:
   • Dados
   • Linkʼs para ou...
O Recurso pode trazer link’s
para as proximas transições

Os Recursos agora trazem consigo:
  • Dados
                    ...
Hypermedia com JAX-RS   Quebrou a firma.
Hypermedia com JAX-RS?
Precisamos de um Assembler de Recursos
public class PedidoXMLAssembler {
	 private final String LIN...
Hypermedia As The Engine
      Of Application State   HATEOAS
HATEOAS - Hypermedia As The Engine
Of Application State

• Os linkʼs informam os próximos passos válidos
• Seguindo estes ...
http://restfulie.caelum.com.br/




Framework para HATEOAS                  Java, Ruby, c#
Client - Java



Order order = new Order();

// place the order
order = service("http://www.caelum.com.br/order").post(ord...
Server - Java
public class Order implements StateResource {

	 public List<Transition> getFollowingTransitions(Restfulie c...
Client - Ruby
# retrieves the resource through GET: the entry point
order = Order.from_web resource_uri

puts "Order price...
Server - Ruby

class Order < ActiveRecord::Base

  acts_as_restfulie do |transitions|
    transitions << [:show]
    trans...
Obrigado.           Luiz Costa
         luiz.costa@caelum.com.br
                 @gutomcosta
                Sergio Junio...
Upcoming SlideShare
Loading in …5
×

Do Rest Ao Restfull - Rio Jug

1,771 views

Published on

Como tornar seus serviços RESTful. Como e porque usar hypermedia. O que é HATEOAS?

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,771
On SlideShare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
Downloads
71
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide
  • Luiz e Sergio :
    Bom dia, nos somos Luiz e Sergio

    Luiz
    O objetivo de nossa apresenta&amp;#xE7;&amp;#xE3;o &amp;#xE9; mostrar REST como uma alternativa a implementa&amp;#xE7;&amp;#xE3;o de Web Services tradicionais.

    Sergio:
    Vamos falar um pouco da teoria e depois mostrar um demo de uma aplica&amp;#xE7;&amp;#xE3;o aplicando essa teoria.
  • Bom, pra come&amp;#xE7;ar, vamos contar uma hist&amp;#xF3;ria que j&amp;#xE1; aconteceu com a gente em uma empresa. Ou melhor, com amigos nossos. Rs
    Se algu&amp;#xE9;m notar alguma semelharn&amp;#xE7;a com a realidade &amp;#xE9; mera coicid&amp;#xEA;ncia.

    Um dos maiores problemas que temos hoje em dia, &amp;#xE9; o de integrar 2 ou mais aplica&amp;#xE7;&amp;#xF5;es n&amp;#xE9;.
    Como fazer para compartilhar informa&amp;#xE7;&amp;#xF5;es entre estas informa&amp;#xE7;&amp;#xF5;es.

    Em uma empresa qualquer, passamos por um problema desses. O que &amp;#xE9; bem comum hoje em dia.
    T&amp;#xED;nhamos v&amp;#xE1;rias aplica&amp;#xE7;&amp;#xF5;es dentro da empresa e estas precisavam se comunicar. Trocar informa&amp;#xE7;l&amp;#xF5;es.
    T&amp;#xED;nhamos a&amp;#xED; o velho problema. Como integrar isso.
    A primeira solu&amp;#xE7;&amp;#xE3;o que foi utilizado &amp;#xE9;:
  • Banco de dados
    Vamos compartilhar as Tabelas que s&amp;#xE3;o comuns para as aplica&amp;#xE7;&amp;#xF5;es e t&amp;#xE1; tudo certo.
    Ent&amp;#xE3;o as aplica&amp;#xE7;&amp;#xF5;es que utilizavam as tabelas de clientes, produtos, iriam acessar a mesma tabela.
    Isso durante um tempo funcionou bem.
    S&amp;#xF3; que as coisas come&amp;#xE7;aram a ficar mais complicadas. V&amp;#xE1;rias outras aplica&amp;#xE7;&amp;#xF5;es foram aparecendo, precisam de acessar informa&amp;#xE7;&amp;#xF5;es de clientes e produtos, ou at&amp;#xE9; mesmo de outras tabelas.
    Isso come&amp;#xE7;ou a gerar um trabalho enorme, manter todas estas tabelas em um estado consistente. Isso era trabalhoso mas de certa forma funcionava.
    At&amp;#xE9; o dia que apreceu um parceiro externo.
    N&amp;#xF3;s precis&amp;#xE1;vamos trocar informa&amp;#xE7;&amp;#xF5;es com um parceiro. Como fazer?
    Algu&amp;#xE9;m deu a solu&amp;#xE7;&amp;#xE3;o, a gente pede pra ele uma tabela, o ip do servidor de banco de dados e constru&amp;#xED;mos a url de conex&amp;#xE3;o e fazemos a conex&amp;#xE3;o direta neste servidor. Brilhante n&amp;#xE9;?
    &amp;#xC9; evidente que este parceiro n&amp;#xE3;o aceito esta solu&amp;#xE7;&amp;#xE3;o, n&amp;#xE3;o iria liberar acesso ao servidor de banco de dados deles. Enfim n&amp;#xE3;o deu muito certo.
    O pessoal mais antigo ent&amp;#xE3;o disse. Vamos fazer troca de arquivos. Isso era muito comum antigamente.
  • O pessoal mais antigo ent&amp;#xE3;o disse. Vamos fazer troca de arquivos. Isso era muito comum antigamente.
    Os 2 parceiros v&amp;#xE3;o combinar alguma coisa sobre como estes arquivos ser&amp;#xE3;o formados e ent&amp;#xE3;o, n&amp;#xF3;s constru&amp;#xED;mos o nosso parser e conseguimos ler os dados destes arquivos.
    Muito legal n&amp;#xE9;.
    Mas e se aparecer um outro parceiro externo? Hoje em dia, n&amp;#xE3;o podemos pensar que nossa aplica&amp;#xE7;&amp;#xE3;o &amp;#xE9; uma ilha, onde somente a gente vai utilizar seus dados.
    Todo mundo quer trocar informa&amp;#xE7;&amp;#xE3;o hoje em dia, se vc for observar, quase tudo &amp;#xE9; integrado, o servi&amp;#xE7;o de cart&amp;#xE3;o de cr&amp;#xE9;dito, a compra de passagens, em uma aplica&amp;#xE7;&amp;#xE3;o de agencia de viagens etc.

    Come&amp;#xE7;aram a surgir v&amp;#xE1;rias op&amp;#xE7;&amp;#xF5;es no mercado, apareceram os famos Objetos Distribu&amp;#xED;dos, com aquele neg&amp;#xF3;cio do CORBA. Era interessante n&amp;#xE9;, eles tinham um discurso que ia resolver estes problemas de integra&amp;#xE7;&amp;#xE3;o com objetos distribu&amp;#xED;dos. Esse neg&amp;#xF3;cio n&amp;#xE3;o vingou n&amp;#xE9;.
    Precisavamos de algo mais padronizado.
    Voltando ao ao problema
  • Podemos utilizar web services. Todo mundo hoje utiliza web service. &amp;#xC9; a forma mais comum de se fazer integra&amp;#xE7;&amp;#xE3;o hoje. J&amp;#xE1; temos um formato padronizado, podemos tirar proveito da interoperabilidade, enfim, v&amp;#xE1;rias vantagens n&amp;#xE9;.;
    Vamos d&amp;#xE1; uma olhada em como eles funcionam.
  • Os Ws s&amp;#xE3;o padronizados, tem uma tal de WS* que define um conjun to de padr&amp;#xF5;es
    Outro coisa interessante, &amp;#xE9; que agora vc n&amp;#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&amp;#xE7;o. Isso &amp;#xE9; oq conhecemos como WSDL. Para vc utilizar o servi&amp;#xE7;o, vc precisa conhecers seu descritor. Vc tem um contrato.

    Como vcs podem perceber, estes web services s&amp;#xE3;o focados em opera&amp;#xE7;&amp;#xF5;es. Vc tem que conhecer quais s&amp;#xE3;o as opera&amp;#xE7;&amp;#xF5;es que vc pode executar sobre o servi&amp;#xE7;o.
    Isso at&amp;#xE9; parece razoavel n&amp;#xE9;, eu preciso saber oq eu possa fazer para interagir com o servi&amp;#xE7;o.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • Vamos d&amp;#xE1; uma olhada em algo que j&amp;#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&amp;#xE1; que est&amp;#xE1; passando o notic&amp;#xE1;rio?
    Vc utiliza a internet.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • REST significa &amp;#x2013; REpresentational State Transfer

    Pontos Chave: &amp;#xC9; um estilo de arquitetura e &amp;#xC9; baseado em um conjunto de principios

    Bom para aproveitar ent&amp;#xE3;o todas as caracter&amp;#xED;sticas da web , o que precisamos em primeiro lugar &amp;#xE9; tentar ser simples, da mesma forma que a web &amp;#xE9;. Isto significa que n&amp;#xE3;o precisamos de nada al&amp;#xE9;m do que j&amp;#xE1; est&amp;#xE1; dispon&amp;#xED;vel na web para implementar aplica&amp;#xE7;&amp;#xF5;es que fazem parte da web.
    REST &amp;#xE9; simples, mas n&amp;#xE3;o &amp;#xE9; pq ele simples que s&amp;#xF3; &amp;#xE9; poss&amp;#xED;vel implementar servi&amp;#xE7;os simples.

    Podemos ver o Rest como um conjunto de princ&amp;#xED;pios que definem como os Web Standards , tal como HTTP, URIs s&amp;#xE3;o utilizados. A id&amp;#xE9;ia ent&amp;#xE3;o &amp;#xE9; que se vc adota estes princ&amp;#xED;p&amp;#xED;os enquanto projeta sua aplica&amp;#xE7;&amp;#xE3;o, esta ir&amp;#xE1; conseguir explorar todos os benef&amp;#xED;cios que a arquitetura web nos tr&amp;#xE1;s.
    Vamos come&amp;#xE7;ar a analisar estes princ&amp;#xED;pios
  • Diferente da vis&amp;#xE3;o tradicional de web services, o que vc exp&amp;#xF5;e em rest s&amp;#xE3;o Recursos.
    Mas o que s&amp;#xE3;o estes Recursos?
    Recursos s&amp;#xE3;o coisas importantes que vc tem na sua aplica&amp;#xE7;&amp;#xE3;o. Eles podem ser algo f&amp;#xED;sico como uma foto, ou um conceito abstrato
    como &amp;#x201C;Como est&amp;#xE1; o tempo agora?&amp;#x201D;.
    Ent&amp;#xE3;o fotos, relatorios, arquivos e at&amp;#xE9; uma lista de buracos da br 101, podem ser recursos.
    Inclusive o resultado de um c&amp;#xE1;lculo. Por exemplo, posso ter um recurso Total de Vendas por Regi&amp;#xE3;o. Isso &amp;#xE9; um recurso algor&amp;#xED;tmico.
    Vale destacar que um recurso identifica alguma coisa. Eu posso ter o recurso Todos os Clientes, mas eu tamb&amp;#xE9;m tenho o Recurso Cliente &amp;#x201C;Jos&amp;#xE9; Maria&amp;#x201D;
    O primeiro, representa todos os clientes, o segundo apenas o jos&amp;#xE9; maria.
    Tudo o que vc vai expor em sua aplica&amp;#xE7;&amp;#xE3;o utilizando REST vai se transformar em Recursos.
  • Ent&amp;#xE3;o agora a gente sabe que expomos recursos. Ent&amp;#xE3;o na minha aplica&amp;#xE7;&amp;#xF5;e eu tenho v&amp;#xE1;rios recursos dispon&amp;#xED;veis para utiliza&amp;#xE7;&amp;#xE3;o em outras aplica&amp;#xE7;&amp;#xF5;es.
    Mas como eu utilizo estes recursos? Vamos pensar como &amp;#xE9; feito nos webServices tradicionais. Vc tem um EndPoint onde vc descobre um WSDL que te d&amp;#xE1; as informa&amp;#xE7;&amp;#xF5;es do Servi&amp;#xE7;o.
    Tem que ter algo para que eu consiga Identificar os recursos que eu tenho na minha apliuca&amp;#xE7;&amp;#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&amp;#xE7;&amp;#xE3;o fa&amp;#xE7;a parte da web, e h&amp;#xE1; um concenso na web sobre IDs. A forma padr&amp;#xE3;o de identificar qualquer coisa na web &amp;#xE9; atrav&amp;#xE9;s de URIs. Ent&amp;#xE3;o para eu acessar os recursos eu vou utilizar URIs, da mesma forma que eu fa&amp;#xE7;o para acessar o site do google.
    Se eu estou desenvolvendo uma aplica&amp;#xE7;&amp;#xE3;o para cuidade de clientes eu posso expor alguns recursos:
    &amp;#x201C;Todos os clientes&amp;#x201D; este vai ser acessado por http://exemplo.com/clientes.
    Repare que este recurso, representa todos os clientes da minha aplica&amp;#xE7;&amp;#xE3;o. Eu n&amp;#xE3;o estou me referindo a um cliente em espec&amp;#xED;fico.
    Se eu quiser fazer isso, ent&amp;#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 &amp;#xE9; comum ver por a&amp;#xED;, uris bem leg&amp;#xED;veis para facilitar sua leitura.
    Agora, como este recurso &amp;#xE9; identific&amp;#xE1;vel, vc pode chegar no Browser e digitar esta URI e ir diretamente at&amp;#xE9; este recurso, ou at&amp;#xE9; mesmo, copiar esta URI e colar em um e-mail e enviar para o setor de marketing oferecer uma promocao a este cliente.
    &amp;#xC9; assim que a web funciona n&amp;#xE9;. Vc sabe as uris dos sites que vc acessa.
  • Uma vez que conseguimos encontrar um recurso e solicitar informa&amp;#xE7;&amp;#xF5;es sobre ele, &amp;#xE9; poss&amp;#xED;vel que estas informa&amp;#xE7;&amp;#xF5;es possam nos levar outros recursos.Ex:Quando solicitamos &amp;#x201C;Cliente n&amp;#xFA;mero 23&quot; podemos ter as informa&amp;#xE7;&amp;#xF5;es do recurso cliente 23 e alem disso, alguns pedidos podem estar associados a este cliente. Ent&amp;#xE3;o como poder&amp;#xED;amos representar isso?
    N&amp;#xF3;s vamos falar de representa&amp;#xE7;&amp;#xF5;es com mais detalhes um pouco a frente, mas por enquanto vamos pensar nestes pontos:
    a) Poder&amp;#xED;amos ter uma representa&amp;#xE7;&amp;#xE3;o do recurso cliente em XML e inclu&amp;#xED;r os dados dos pedido junto desta representa&amp;#xE7;&amp;#xE3;o
  • b) Poder&amp;#xED;amos ter uma representa&amp;#xE7;&amp;#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&amp;#xE3;o continua sua navega&amp;#xE7;&amp;#xE3;o digitando novos endere&amp;#xE7;os na barra do se browser. O que vc faz &amp;#xE9; seguir os links. Se nossa aplica&amp;#xE7;&amp;#xE3;o quer fazer parte da web, temos que incorparar estas caracter&amp;#xED;sticas nela.Assim n&amp;#xF3;s utilizamos links para continuar a nevaga&amp;#xE7;&amp;#xE3;o pela nossa aplica&amp;#xE7;&amp;#xE3;o, da mesma forma que a web. Esse &amp;#xE9; o conceito conhecido como Hipermedia: os documentos n&amp;#xE3;o s&amp;#xE3;o apenas dados, mas links para outros recursos.
  • Bom, falamos de URIs e Recursos, e por &amp;#xFA;ltimo falamos de Links. Como podemos utilizar estas URIs e Links em nossa aplica&amp;#xE7;&amp;#xE3;o?Quando vc v&amp;#xEA; uma URI em alguma propaganda em um Outdoor, ou at&amp;#xE9; mesmo algu&amp;#xE9;m informando isso em um programa de televis&amp;#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&amp;#xE3;o para todo recurso. O seja, todo recurso suporta a mesmo conjunto de instrucoes, ou o mesmo conjunto de opera&amp;#xE7;&amp;#xF5;es. Em toda Web, existem apenas algumas coisas b&amp;#xE1;sicas que vc pode fazer com recursos. O protocolo HTTP nos fornece quatro m&amp;#xE9;todos b&amp;#xE1;sicos para opera&amp;#xE7;&amp;#xF5;es mais comuns. Ele chama estes m&amp;#xE9;todos de verbos, s&amp;#xE3;o eles (GET, POST,PUT,DELETE ) e alem deles temos (HEAD e OPTIONS).
    Isto significa que estes m&amp;#xE9;todos est&amp;#xE3;o definidos na especifica&amp;#xE7;&amp;#xE3;o do protocolo HTTP.&amp;#xC9; como se imagin&amp;#xE1;ssemos (em OO) que existe uma interface que todo recurso precisasse estender.
  • Como temos uma interface padr&amp;#xE3;o definida, eu posso confiar que serei capaz de obter uma representa&amp;#xE7;&amp;#xE3;o de um recurso usando um m&amp;#xE9;todo GET. Eu posso confiar nisso pq a semantica do m&amp;#xE9;todo GET est&amp;#xE1; definida na especifica&amp;#xE7;&amp;#xE3;o do HTTP.Ent&amp;#xE3;o o que o meu Browser faz quando eu digito uma URI &amp;#xE9; enviar um solicita&amp;#xE7;&amp;#xE3;o usando o m&amp;#xE9;todo GET do HTTP.

    Mas pera a&amp;#xED;. Eu tenho 4 m&amp;#xE9;todos dispon&amp;#xED;veis para realizar todas as opera&amp;#xE7;&amp;#xF5;es em um recurso? Esse neg&amp;#xF3;cio t&amp;#xE1; meio esquisito.Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Servi&amp;#xE7;o&quot; web hoje.
    Temos um &quot;Servi&amp;#xE7;o&quot; e v&amp;#xE1;rios m&amp;#xE9;todos que atuam sobre este servi&amp;#xE7;o.&amp;#xA0; Se quisermos utilizar este servi&amp;#xE7;o precisamos conhecer antes a sua interface. N&amp;#xE3;o tem como utilizaramos sem conhecer esta interface.

    Utilizando Rest n&amp;#xF3;s utilizamos uma forma mais gen&amp;#xE9;rica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padr&amp;#xE3;o? Ent&amp;#xE3;o n&amp;#xF3;s precisamos utilizar somente os m&amp;#xE9;todos do HTTP. Mas como resolver tudo com estes m&amp;#xE9;todos? Talvez va&amp;#xE3;o existir situa&amp;#xE7;&amp;#xF5;es que n&amp;#xE3;o vamos conseguir resolver com apenas estes m&amp;#xE9;todos. A resposta para isto &amp;#xE9;, vamos criar v&amp;#xE1;rios recursos.Na implementa&amp;#xE7;&amp;#xE3;o tradicional temos apenas um 1 servi&amp;#xE7;o que tem v&amp;#xE1;rios m&amp;#xE9;todos. Na nossa implementa&amp;#xE7;&amp;#xE3;o baseada em rest, vamos ter v&amp;#xE1;rios recursos, e cada recurso vai ser manipulado pelos m&amp;#xE9;todos default do http.
  • representa um pedido em especifico, o template {identificador} informa que ser&amp;#xE1; utilizado algo que identifique um pedido em especifico, pode ser um n&amp;#xFA;mero.As opera&amp;#xE7;&amp;#xF5;es s&amp;#xE3;o:

    Agora n&amp;#xF3;s utilizamos os m&amp;#xE9;todos da interface padr&amp;#xE3;o sobre os recursos criados. O m&amp;#xE9;todo GET sobre um pedido especifico tem o mesmo efeito que o metodo obterDetalhesDeUmPedido().Com uma abordagem como essa,existe um n&amp;#xFA;mero fixo de opera&amp;#xE7;&amp;#xF5;es, mas podemos representar milh&amp;#xF5;es de pedidos diferentes atrav&amp;#xE9;s de recursos.

    Ent&amp;#xE3;o quando eu quero obter a informa&amp;#xE7;&amp;#xE3;o de um recurso eu utilizo o m&amp;#xE9;todo GET.
    Quando vc faz uma requisi&amp;#xE7;&amp;#xE3;o GET em um recurso vc n&amp;#xE3;o est&amp;#xE1; fazendo qualquer altera&amp;#xE7;&amp;#xE3;o no estado do Servidor.
    Qualquer quantidade de requisi&amp;#xE7;&amp;#xF5;es GET que eu fizer no mesmo recurso, ter&amp;#xE1; sempre o mesmo efeito.
    Ent&amp;#xE3;o uma opera&amp;#xE7;&amp;#xE3;o GET &amp;#xE9; segura, n&amp;#xE3;o h&amp;#xE1; mudan&amp;#xE7;as de estado.

    Para criar um pedido utilizamos o POST ou o PUT.
    A diferen&amp;#xE7;a &amp;#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&amp;#xFA;mero &amp;#xE9; um ID que s&amp;#xF3; ser&amp;#xE1; conhecido ap&amp;#xF3;s a cria&amp;#xE7;&amp;#xE3;o do recurso, utilizamos post.
    Se queremos criar um recuro j&amp;#xE1; com uma URI definida, ent&amp;#xE3;o utilizamos o PUT&gt;

    E para excluir um recurso utilzamos o DELETE
    Todas estas itera&amp;#xE7;&amp;#xF5;es podem ter problemas, e para utilizamos o c&amp;#xF3;digo de erro do HTTP. O clietne deve verificar estes codigos de erro da requisi&amp;#xE7;&amp;#xE3;o para saber se deu tudo certo ou n&amp;#xE3;o.
    E a partir da&amp;#xED;, qualquer aplica&amp;#xE7;&amp;#xE3;o que saiba conversar com o HTTP pode utilizar nossos Recursos. Inclusive seu Browser!!!
  • representa todos os pedidos, ou seja toda a cole&amp;#xE7;&amp;#xE3;o de pedidos dispon&amp;#xED;veis.Podemos descrever o que as opera&amp;#xE7;&amp;#xF5;es padr&amp;#xE3;o fazem para este recurso como:
  • Um recurso &amp;#xE9; apenas uma id&amp;#xE9;ia, algo conceitual. Quando utilizamos uma URI para chegar at&amp;#xE9; um recurso, estamos na verdade pedindo o servidor web exatamente o qu&amp;#xEA;? O Servidor web n&amp;#xE3;o pode nos enviar uma id&amp;#xE9;ia. O que um servidor sabe responder para n&amp;#xF3;s, &amp;#xE9; apenas um conjunto de bytes. Este bytes normalmente, deve estar em formato espec&amp;#xED;fico, em uma linguagem espec&amp;#xED;fica. Esta linguagem e este formato &amp;#xF3; que chamos de representa&amp;#xE7;&amp;#xE3;o de um recurso.Um mesmo recurso, pode ter diversas representa&amp;#xE7;&amp;#xF5;es. Por exemplo, eu posso querer exibir os dados do meu Recurso Cliente em um Browser, para isso eu podeira utilizar uma representa&amp;#xE7;&amp;#xE3;o deste recurso em XHTML. Ou ent&amp;#xE3;o eu poderia disponibilizar os dados deste recurso para uma outra aplica&amp;#xE7;&amp;#xE3;o. Para isso eu poderia utilizar XML.
    O fato &amp;#xE9; que podem haver v&amp;#xE1;rias representa&amp;#xE7;&amp;#xF5;es para um mesmo recurso.
    Aqui tem os algumas delas.
  • Um mesmo recurso, pode ter diversas representa&amp;#xE7;&amp;#xF5;es. E quando solicitamos informa&amp;#xE7;&amp;#xF5;es sobre um recurso atrav&amp;#xE9;s da chamada de m&amp;#xE9;todos padr&amp;#xE3;o, n&amp;#xF3;s tamb&amp;#xE9;m podemos informar, qual &amp;#xE9; a representa&amp;#xE7;&amp;#xE3;o que esperamos.
    N&amp;#xF3;s temos um recurso que &amp;#xE9;: &quot;/pedidos/2009/11&quot; (pedidos de novembro de 2009). Ele pode ser acessado por uma URI: http://exemplo.com/pedidos/2009/11.Quando acessamos esta URI atrav&amp;#xE9;s de um browser, o que esperamos como resposta? Uma p&amp;#xE1;gina web contendo os dados dos pedidos de novembro de 2009. J&amp;#xE1; quando acessamos por uma aplica&amp;#xE7;&amp;#xE3;o, talvez fosse melhor, receber estes dados em uma outra representa&amp;#xE7;&amp;#xE3;o ou formato, por exemplo XML, ou at&amp;#xE9; mesmo em um arquivo texto separado por v&amp;#xED;rgulas.

    Se vc fornece os formatos xHTML e XML para representa&amp;#xE7;&amp;#xF5;es do seu recurso, ele pode ser consumido n&amp;#xE3;o somente pela sua aplica&amp;#xE7;&amp;#xE3;o, mas por qualquer Web Brower ou seja, as informa&amp;#xE7;&amp;#xF5;es de sua aplica&amp;#xE7;&amp;#xE3;o podem estar dispon&amp;#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&amp;#xE7;&amp;#xE3;o em XHTML.
    Agora se for para uma outra aplica&amp;#xE7;&amp;#xE3;o utilizar vamos expor os dados em xml.
    Aqui alguns exemplos de como isso poderia ser utilizado.
  • O &amp;#xFA;ltimo princ&amp;#xED;pio que n&amp;#xF3;s gostar&amp;#xED;amos de falar &amp;#xE9; sobre falta de estado. A falta de estado significa que toda a solicita&amp;#xE7;&amp;#xE3;o HTTP ocorre em um isolamento completo. Quando o cliente faz uma solicita&amp;#xE7;&amp;#xE3;o HTTP, inclui todas as informa&amp;#xE7;&amp;#xF5;es necess&amp;#xE1;rias para o servidor processar e responder esta solicita&amp;#xE7;&amp;#xE3;o.O princ&amp;#xED;pio da falta de estado torna as coisas muito mais simples. Um cliente pode fazer solicita&amp;#xE7;&amp;#xF5;es para um mesmo recurso, diversas vezes. Uma servidor pode parar de responder por algum problema t&amp;#xE9;cnico e interromper a solicita&amp;#xE7;&amp;#xE3;o no meio do caminho sem maiores problema, visto que o cliente pode reenviar a novamente.
  • Mas &amp;#xE9; evidente que precisamos armazenar os dados de nosso Recurso, pois s&amp;#xE3;o estes dados que nos fazem querer utiliz&amp;#xE1;-lo. A falta de estado que estamos falando aqui &amp;#xE9; a falta de estado da aplica&amp;#xE7;&amp;#xE3;o. Existe uma diferen&amp;#xE7;a entre falta de estado da aplica&amp;#xE7;&amp;#xE3;o e falta de estado do recurso.

    A falta de estado da aplica&amp;#xE7;&amp;#xE3;o significa que o cliente &amp;#xE9; quem deve ser o respons&amp;#xE1;vel por gerenciar seu pr&amp;#xF3;prio caminho&amp;#xA0; pela aplica&amp;#xE7;&amp;#xE3;o. O servidor nem sabe que existe um cliente conectado. Agora o estado do recurso &amp;#xE9; o mesmo para todo o cliente e seu lugar &amp;#xE9; no servidor. Por exemplo, quando voc&amp;#xEA; faz um upload de fotos no Flickr ele cria um novo recurso que tem sua pr&amp;#xF3;pria URI e pode ser destino de futuras solicita&amp;#xE7;&amp;#xF5;es. Esta foto &amp;#xE9; parte do estado do Recurso e ficar&amp;#xE1; no servidor at&amp;#xE9; que algum cliente a apague.
  • A falta de estado na apliaca&amp;#xE7;&amp;#xE3;o nos traz uma vantagem enorme quando falamos em escalabilidade.
    Imagine que eu tenho um servidor atendendo uma aplica&amp;#xE7;&amp;#xE3;o.
    Tem um cliente acessando, e o servidor respondendo.
    De repente come&amp;#xE7;am a aparecer outros clientes acessando sua aplica&amp;#xE7;&amp;#xE3;o. Ela come&amp;#xE7;a a se tornar popular, o n&amp;#xFA;mero de requisi&amp;#xE7;&amp;#xF5;es vai aumentando.
    At&amp;#xE9; que chega um ponto que seu servidor abre o bico. E a&amp;#xED; o que fazer?
  • A falta de estado na apliaca&amp;#xE7;&amp;#xE3;o nos traz uma vantagem enorme quando falamos em escalabilidade.
    Imagine que eu tenho um servidor atendendo uma aplica&amp;#xE7;&amp;#xE3;o.
    Tem um cliente acessando, e o servidor respondendo.
    De repente come&amp;#xE7;am a aparecer outros clientes acessando sua aplica&amp;#xE7;&amp;#xE3;o. Ela come&amp;#xE7;a a se tornar popular, o n&amp;#xFA;mero de requisi&amp;#xE7;&amp;#xF5;es vai aumentando.
    At&amp;#xE9; que chega um ponto que seu servidor abre o bico. E a&amp;#xED; o que fazer?
  • A falta de estado na apliaca&amp;#xE7;&amp;#xE3;o nos traz uma vantagem enorme quando falamos em escalabilidade.
    Imagine que eu tenho um servidor atendendo uma aplica&amp;#xE7;&amp;#xE3;o.
    Tem um cliente acessando, e o servidor respondendo.
    De repente come&amp;#xE7;am a aparecer outros clientes acessando sua aplica&amp;#xE7;&amp;#xE3;o. Ela come&amp;#xE7;a a se tornar popular, o n&amp;#xFA;mero de requisi&amp;#xE7;&amp;#xF5;es vai aumentando.
    At&amp;#xE9; que chega um ponto que seu servidor abre o bico. E a&amp;#xED; o que fazer?
  • A falta de estado na apliaca&amp;#xE7;&amp;#xE3;o nos traz uma vantagem enorme quando falamos em escalabilidade.
    Imagine que eu tenho um servidor atendendo uma aplica&amp;#xE7;&amp;#xE3;o.
    Tem um cliente acessando, e o servidor respondendo.
    De repente come&amp;#xE7;am a aparecer outros clientes acessando sua aplica&amp;#xE7;&amp;#xE3;o. Ela come&amp;#xE7;a a se tornar popular, o n&amp;#xFA;mero de requisi&amp;#xE7;&amp;#xF5;es vai aumentando.
    At&amp;#xE9; que chega um ponto que seu servidor abre o bico. E a&amp;#xED; o que fazer?
  • Podemos escalar a vontade os servidores web.
    At&amp;#xE9; que o problema mude de lugar. (BD)
  • Podemos escalar a vontade os servidores web.
    At&amp;#xE9; que o problema mude de lugar. (BD)
  • Bom, pra come&amp;#xE7;ar, vamos contar uma hist&amp;#xF3;ria que j&amp;#xE1; aconteceu com a gente em uma empresa. Ou melhor, com amigos nossos. Rs
    Se algu&amp;#xE9;m notar alguma semelharn&amp;#xE7;a com a realidade &amp;#xE9; mera coicid&amp;#xEA;ncia.

    Um dos maiores problemas que temos hoje em dia, &amp;#xE9; o de integrar 2 ou mais aplica&amp;#xE7;&amp;#xF5;es n&amp;#xE9;.
    Como fazer para compartilhar informa&amp;#xE7;&amp;#xF5;es entre estas informa&amp;#xE7;&amp;#xF5;es.

    Em uma empresa qualquer, passamos por um problema desses. O que &amp;#xE9; bem comum hoje em dia.
    T&amp;#xED;nhamos v&amp;#xE1;rias aplica&amp;#xE7;&amp;#xF5;es dentro da empresa e estas precisavam se comunicar. Trocar informa&amp;#xE7;l&amp;#xF5;es.
    T&amp;#xED;nhamos a&amp;#xED; o velho problema. Como integrar isso.
    A primeira solu&amp;#xE7;&amp;#xE3;o que foi utilizado &amp;#xE9;:
  • Do Rest Ao Restfull - Rio Jug

    1. 1. Do REST ao RESTful Luiz Costa luiz.costa@caelum.com.br @gutomcosta Sergio Junior sergio.junior@caelum.com.br @sergioazevedo
    2. 2. Integração O velho problema
    3. 3. O Banco de Dados Solução Prática #1
    4. 4. Transferência de Arquivos Solução Prática #2
    5. 5. Web Services Solução Prática #3
    6. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. HTTP faz isso tudo mesmo? Me mostre um Exemplo
    16. 16. Web O Sistema Escalável
    17. 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. 18. E hoje? smtp: email bittorrent: arquivos irc, im: chat ssh: acesso remoto
    19. 19. home banking: www compras: www calendário: www email: www chat: www documentos: www conteúdo restrito: www sexo: www
    20. 20. 2000 - Roy Fielding why the web? why? Do REST Ao RESTful Www.caelum.com.br
    21. 21. REpresentational State Transfer O que é isso?
    22. 22. Recursos É algo interessante para sua aplicação. Fotos, relatorios, arquivos, Lista de buracos da BR 101. Tudo é um recurso.
    23. 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. 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. 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. 26. Interface Uniforme Mantendo as coisas simples
    27. 27. Interface Uniforme
    28. 28. Interface Uniforme Agora o foco são os Recursos.
    29. 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. 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. 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. 32. Representações Atom
    33. 33. Escolhendo uma Representação GET /pedidos/2009/11 HTTP 1.1 HOST exemplo.com Accept: application/xml 200 OK <pedido … />
    34. 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. 35. Falta de Estado Http é Stateless
    36. 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. 37. Escalabilidade Falta de estado pode ser bom.
    38. 38. Escalabilidade Falta de estado pode ser bom.
    39. 39. Escalabilidade Falta de estado pode ser bom.
    40. 40. Escalabilidade Falta de estado pode ser bom.
    41. 41. Escalabilidade Falta de estado pode ser bom.
    42. 42. Escalabilidade Falta de estado pode ser bom.
    43. 43. Escalabilidade Falta de estado pode ser bom.
    44. 44. Escalabilidade Falta de estado pode ser bom.
    45. 45. A solução REST para Java JSR-311 - JAX-RS
    46. 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. 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. 48. A vida de um recurso Nao é apenas CRUD
    49. 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. 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. 51. Os possíveis estados de um Pedido
    52. 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. 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. 54. Hypermedia com JAX-RS Quebrou a firma.
    55. 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. 56. Hypermedia As The Engine Of Application State HATEOAS
    57. 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. 58. http://restfulie.caelum.com.br/ Framework para HATEOAS Java, Ruby, c#
    59. 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. 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. 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. 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. 63. Obrigado. Luiz Costa luiz.costa@caelum.com.br @gutomcosta Sergio Junior sergio.junior@caelum.com.br @sergioazevedo

    ×