Your SlideShare is downloading. ×
  • Like
Web Services Rest
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Web Services Rest

  • 9,030 views
Published

 

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
9,030
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
298
Comments
0
Likes
12

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Bruno Pereira Web Services REST
  • 2. Agenda
    • Definição e um pouco de história
    • Motivação
    • Arquitetura
    • Implementação
    • Conclusão
  • 3. REST - Definição
    • REpresentational State Transfer
    • Estilo de arquitetura
    • Termo proposto por Roy Fielding
    • WS com arquitetura da internet
    • Exploração extensa do HTTP
  • 4. Um pouco de história
    • Final da década de 90:
      • Aplicações distribuídas com HTTP + XML
      • Implementações customizadas sempre
      • Protocolos próprios
      • Diferentes abordagens de segurança, controle transacional, etc.
    Desafio: Como vender middleware assim?
  • 5. Surgimento WS-*
      • Sem padrões, difícil vender middleware
      • Fabricantes padronizam implementações
    WSDL SOAP UDDI WS-Security WS-Policy WS-Addressing Complexidade WS-Transaction
  • 6. Surgimento REST
    • Tese Roy Fielding
    • Conjunto de regras simples
    • Grupos de estudo IETF
    • Especificações após uso maduro
  • 7. Analogia das evoluções WS-* REST Modelo OSI TCP/IP Muitas specs antes das implementações Modelo waterfall/cascata Regras simples Specs acompanham implementações Modelo incremental Scrum anyone??
  • 8. Motivação
    • Porque implementar serviços REST?
    • Protocolos menos complexos
    • Mais poder e flexibilidade
    • Arquitetura amplamente disponível
    • Menos overhead de protocolo
    No Silver Bullet!
  • 9. Des-Motivação
    • Quando NÃO implementar serviços REST?
    • Integração com produtos fechados WS-*
    • Quando WS-Transaction fizer sentido
    • Quando WS-Security fizer sentido
    • Quando não houver API HTTP razoável
  • 10. Arquitetura dos web services REST
  • 11. Estilo de acesso aos serviços
  • 12. Estilo declarativo x imperativo GET /usuario/123456 O quê Como Método HTTP URI do recurso <soap:Envelope> <soap:Body> <globo: consultarUsuario > <id>123456</id> </globo: consultarUsuario > </soap:Body> </soap:Envelope> fazerEstaOperacao
  • 13. Implementação de serviços REST
  • 14. Problema proposto
    • Leilão do Mercado Livre
    • Vendedor anuncia produto
    • Interessados realizam ofertas
    • Vendedor aceita melhor oferta
    • Vendedor e comprador se avaliam
  • 15. Serviços oferecidos
    • Anunciar item
    • Buscar ítens do vendedor
    • Cadastrar usuário
    • Realizar oferta
    • Retirar oferta
    • Buscar ofertas do item
    • Buscar melhor oferta
    • Aceitar melhor oferta
    • Avaliar usuário
    • Buscar avaliações do usuário
  • 16. Modelagem com recursos
    • Recursos identificados:
    • Usuário
    • Item (produto)
    • Oferta
    • Avaliação
    Como manipular estes recursos? Defina seu protocolo de comunicação REST
  • 17. Protocolo de comunicação REST
    • Perguntas importantes:
    • Quais são os recursos?
    • Quais são as URIs?
    • Quais são os formatos manipulados?
    • Que métodos HTTP são aceitos em cada URI?
    • Que status HTTP deve ser retornado em cada situação?
    • Que cabeçalhos HTTP são relevantes em cada situação?
  • 18. Protocolo de comunicação REST GET, POST, PUT, DELETE SELECT, INSERT, UPDATE, DELETE !=
    • Quanto mais CRUD, mais fácil definir protocolo
    • REST é bem mais do que CRUD
    • REST envolve interações entre Recursos
    • Como modelar serviço de “Aceitar melhor oferta”?
    • Trivial com WS-*, não-trivial com REST
    • Paradigma diferente, modelagem diferente
  • 19. Protocolo de comunicação REST Não posso usar PUT e DELETE, que posso fazer?? 1. Reclamar 2. POST com x-http-method-override E se eu precisar enviar dados em uma requisição sem corpo (HTTP DELETE)?? Mesma receita!
  • 20. Protocolo de comunicação REST Com URI + método, você é capaz de deduzir qual é o serviço em questão? POST /avaliacao/de/{id}/para/{id} GET /avaliacao/{id} POST GET /usuario/{id}/itens GET /usuario/{id}/avaliacoes PUT GET /usuario/{id} POST /usuario DELETE PUT GET /oferta/{id} POST GET /item/{id}/ofertas PUT GET /item/{id} Método URI
  • 21. Fluxo de Processamento
    • Validar URI
    • Validar método HTTP
    • Obter parâmetros da URI
    • Interpretar corpo da requisição
    • Processamento do serviço
    • Gerar resposta
  • 22. Implementação – Com um certo trabalho Processamento do serviço Gerar resposta Validar URI Validar método HTTP Controle customizado de URIs existentes e métodos aceitos Obter parâmetros da URI Quebra manual da URI para extrair parâmetros Interpretar corpo da requisição Manipulação direta do corpo da requisição. Validações e conversões de formatos são customizadas Manipulação do status e corpo da resposta é feito diretamente.
  • 23. Implementação – JAX-RS/Jersey Processamento do serviço Gerar resposta Validar URI Validar método HTTP Anotações sobre classes e métodos Obter parâmetros da URI Injeção de dependências Interpretar corpo da requisição Anotações declaram tipos de conteúdo aceitos. Consumo do corpo é automático. API para definir corpo e status da resposta em alto nível. Fácil suporte a diferentes formatos.
  • 24. JAX-RS/Jersey
    • URIs mapeadas em classes/métodos
    • Parâmetros extraídos das URIs
    • Conversões xml/json/etc -> Java
    • Conversões Java -> xml/json/etc
    • Manipulação de status/headers HTTP
  • 25. Flexibilidade nas respostas Me diga o que queres Seja feita vossa vontade Accept: text/xml, application/json <usuario> <login>blpsilva</login> </usuario> <usuario> <login>teste999</login> </usuario> &quot;usuarios&quot;:[ { &quot;login&quot;:&quot;blpsilva&quot;, }, { &quot;login&quot;:&quot;teste999&quot;, } ] OU
    • Uma interface,
    • múltiplos formatos
  • 26. Flexibilidade nas requisições Me diga o que estás mandando Content-Type: text/xml; OU
    • Uma interface,
    • múltiplos formatos!
    charset=UTF-8 Content-Type: application/json; charset=ISO-8859-1 Eu converto e processo
  • 27. OK, show me the code!!!
  • 28. Parsing de URIs @Path(&quot;usuario&quot;) public class UsuarioResource { @GET @Path(&quot;{usuarioId}&quot;) @ProduceMime(&quot;text/xml&quot;) public Response buscarUsuario(@PathParam(&quot;usuarioId&quot;) String usuarioId)
    • UsuarioResource trata de /usuario
    • buscarUsuario trata de GET /usuario/{usuarioId}
    • Parâmetro usuarioId injetado no método
  • 29. Parsing de URIs @Path(&quot;avaliacao&quot;) public class AvaliacaoResource { @POST @Path(&quot;de/{avaliador}/para/{avaliado}&quot;) public Response avaliarUsuario( @Context UriInfo uriInfo, @PathParam(&quot;avaliador&quot;) String avaliador, @PathParam(&quot;avaliado&quot;) String avaliado, Avaliacao avaliacao) {}
    • AvaliacaoResource trata de /avaliacao
    • avaliarUsuario:
    • POST /avaliacao/de/{avaliador}/para/{avaliado}
    • 2 parâmetros extraídos da URI
    • Avaliação consumida do corpo da requisição
  • 30. Interpretar corpo da requisição @ConsumeMime( { &quot;text/xml&quot;, &quot;application/json&quot; }) public class AvaliacaoResource { @POST @Path(&quot;de/{avaliador}/para/{avaliado}&quot;) public Response avaliarUsuario(@Context UriInfo uriInfo, @PathParam(&quot;avaliador&quot;) String avaliador, @PathParam(&quot;avaliado&quot;) String avaliado, Avaliacao avaliacao )
    • AvaliacaoResource aceita XML e JSON
    • Avaliação em XML/JSON é injetada no método
    • Cliente especifica content-type na requisição
  • 31. Geração da resposta @ProduceMime( { &quot;text/xml&quot;, &quot;application/json&quot; }) public class AvaliacaoResource { @GET @Path(&quot;{avaliacaoId}&quot;) public Response buscar(@PathParam(&quot;avaliacaoId&quot;) String avaliacaoId){ Avaliacao avaliacao = avaliacaoService.buscar(avaliacaoId); if(avaliacao == null){ return Response.status(404).build(); } return Response.ok(avaliacao).build(); }
    • AvaliacaoResource gera XML ou JSON
    • Cliente envia tipo desejado no header Accept
    • API fácil para definir corpo e status da resposta
    • Diferentes formatos tratados declarativamente
  • 32. Mapeamento Java <-> XML
    • JAXB é a forma padrão, sempre disponível
    • Anotações mapeiam classes e atributos
    • Jersey gera JSON a partir do XML gerado
    @XmlRootElement(name = &quot;feedback&quot;) public class Avaliacao { @XmlElement(name = &quot;feedbackCode&quot;) private String codAvaliacao; @XmlElement(name = &quot;rater&quot;) private Usuario avaliador; @XmlElement(name = &quot;positive&quot;) private boolean positiva; @XmlElement(name = &quot;comment&quot;) private String comentario; } JAXB é muito flexível nos mapeamentos
  • 33. Parsing do corpo da requisição
    • Recurso declara formatos esperados
    • JAX-RS faz conversões Java <-> diferentes formatos
    • E se o corpo da requisição veio inválido?
    • Status HTTP 400 – Bad Request
    Como indicar o erro? <erro> <codigo> 2319 </codigo> <mensagem> Atributo XPTO é obrigatório </mensagem> </erro> <erros> <erro> <codigo> 2319 </codigo> <mensagem> Atributo XPTO é obrigatório </mensagem> </erro> ... </erros> OU
  • 34. Clientes Java
    • Requisições HTTP com commons-http-client
    • Mapeamento Java/XML e XML/Java com XStream ou JAXB
    • Status HTTP é o mais importante
    • Alguns headers são importantes também
  • 35. Exemplo: Avaliação de usuário
    • Obter usuário avaliador e o avaliado
    • Obter dados da avaliação
    • Montar URI da avaliação
    • Gerar corpo da requisição
    • Conferir resposta
    Cliente:
  • 36. Exemplo: Avaliação de usuário
    • Validar URI + método HTTP
    • Parsing da URI para obtenção dos usuários
    • Parsing do corpo da requisição
    • Chamada ao Service Layer
    • Geração da resposta
    Servidor:
    • Status HTTP da resposta
    • Header Location
    • RESTFul DSL
  • 37. Principais Status HTTP Sucesso na solicitação. Resposta sem corpo. 204 Tipo de conteúdo não suportado 415 Erro interno no servidor 500 Método HTTP não permitido para a URI 405 Recurso inexistente 404 Requisição inválida 400 Recurso criado com sucesso 201 Solicitação realizada com sucesso 200 Utilização Status
  • 38. Dúvidas comuns
    • Como tratar a paginação de resultados?
    • Como implementar links entre recursos?
    • Como lidar com acessos concorrentes?
    • Como autenticar/autorizar operações?
    Atom + AtomPub + Apache Abdera
    • Blueprint de implementação REST
    • Excelente para conteúdo web
    • Google, Microsoft e Globo.com já usam
  • 39. Descritores de serviços REST WADL Enorme debate. Não existe padrão. Você decide! Combinação estranha. Faz algum sentido? Coleções disponíveis e tipos de conteúdo aceitos. Precisamos de um WSDL RESTful? WSDL 2.0 permite descrever REST Documento de serviços AtomPub Lista URIs, métodos HTTP e tipos de conteúdo aceitos. Gerado automaticamente pelo Jersey.
  • 40. Conclusão
    • Web services antigamente:
    • Troca de performance por interoperabilidade
    • Web services atualmente:
    • Alta performance E interoperabilidade
    • Flexibilidade absoluta
    • Web services no futuro:
    • Forma padrão de comunicação?
    • REST everywhere
  • 41. Dúvidas??
  • 42. Quer conhecer mais? JM 56 (REST) – Abril/2008 JM 60 (JAX-RS/Jersey) – Agosto/2008
  • 43. Contato [email_address] http://brunopereira.org