Web Services Rest

10.047 visualizações

Publicada em

Publicada em: Tecnologia, Negócios
0 comentários
12 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
10.047
No SlideShare
0
A partir de incorporações
0
Número de incorporações
593
Ações
Compartilhamentos
0
Downloads
338
Comentários
0
Gostaram
12
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Web Services Rest

  1. 1. Bruno Pereira Web Services REST
  2. 2. Agenda <ul><li>Definição e um pouco de história </li></ul><ul><li>Motivação </li></ul><ul><li>Arquitetura </li></ul><ul><li>Implementação </li></ul><ul><li>Conclusão </li></ul>
  3. 3. REST - Definição <ul><li>REpresentational State Transfer </li></ul><ul><li>Estilo de arquitetura </li></ul><ul><li>Termo proposto por Roy Fielding </li></ul><ul><li>WS com arquitetura da internet </li></ul><ul><li>Exploração extensa do HTTP </li></ul>
  4. 4. Um pouco de história <ul><li>Final da década de 90: </li></ul><ul><ul><li>Aplicações distribuídas com HTTP + XML </li></ul></ul><ul><ul><li>Implementações customizadas sempre </li></ul></ul><ul><ul><li>Protocolos próprios </li></ul></ul><ul><ul><li>Diferentes abordagens de segurança, controle transacional, etc. </li></ul></ul>Desafio: Como vender middleware assim?
  5. 5. Surgimento WS-* <ul><ul><li>Sem padrões, difícil vender middleware </li></ul></ul><ul><ul><li>Fabricantes padronizam implementações </li></ul></ul>WSDL SOAP UDDI WS-Security WS-Policy WS-Addressing Complexidade WS-Transaction
  6. 6. Surgimento REST <ul><li>Tese Roy Fielding </li></ul><ul><li>Conjunto de regras simples </li></ul><ul><li>Grupos de estudo IETF </li></ul><ul><li>Especificações após uso maduro </li></ul>
  7. 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. 8. Motivação <ul><li>Porque implementar serviços REST? </li></ul><ul><li>Protocolos menos complexos </li></ul><ul><li>Mais poder e flexibilidade </li></ul><ul><li>Arquitetura amplamente disponível </li></ul><ul><li>Menos overhead de protocolo </li></ul>No Silver Bullet!
  9. 9. Des-Motivação <ul><li>Quando NÃO implementar serviços REST? </li></ul><ul><li>Integração com produtos fechados WS-* </li></ul><ul><li>Quando WS-Transaction fizer sentido </li></ul><ul><li>Quando WS-Security fizer sentido </li></ul><ul><li>Quando não houver API HTTP razoável </li></ul>
  10. 10. Arquitetura dos web services REST
  11. 11. Estilo de acesso aos serviços
  12. 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. 13. Implementação de serviços REST
  14. 14. Problema proposto <ul><li>Leilão do Mercado Livre </li></ul><ul><li>Vendedor anuncia produto </li></ul><ul><li>Interessados realizam ofertas </li></ul><ul><li>Vendedor aceita melhor oferta </li></ul><ul><li>Vendedor e comprador se avaliam </li></ul>
  15. 15. Serviços oferecidos <ul><li>Anunciar item </li></ul><ul><li>Buscar ítens do vendedor </li></ul><ul><li>Cadastrar usuário </li></ul><ul><li>Realizar oferta </li></ul><ul><li>Retirar oferta </li></ul><ul><li>Buscar ofertas do item </li></ul><ul><li>Buscar melhor oferta </li></ul><ul><li>Aceitar melhor oferta </li></ul><ul><li>Avaliar usuário </li></ul><ul><li>Buscar avaliações do usuário </li></ul>
  16. 16. Modelagem com recursos <ul><li>Recursos identificados: </li></ul><ul><li>Usuário </li></ul><ul><li>Item (produto) </li></ul><ul><li>Oferta </li></ul><ul><li>Avaliação </li></ul>Como manipular estes recursos? Defina seu protocolo de comunicação REST
  17. 17. Protocolo de comunicação REST <ul><li>Perguntas importantes: </li></ul><ul><li>Quais são os recursos? </li></ul><ul><li>Quais são as URIs? </li></ul><ul><li>Quais são os formatos manipulados? </li></ul><ul><li>Que métodos HTTP são aceitos em cada URI? </li></ul><ul><li>Que status HTTP deve ser retornado em cada situação? </li></ul><ul><li>Que cabeçalhos HTTP são relevantes em cada situação? </li></ul>
  18. 18. Protocolo de comunicação REST GET, POST, PUT, DELETE SELECT, INSERT, UPDATE, DELETE != <ul><li>Quanto mais CRUD, mais fácil definir protocolo </li></ul><ul><li>REST é bem mais do que CRUD </li></ul><ul><li>REST envolve interações entre Recursos </li></ul><ul><li>Como modelar serviço de “Aceitar melhor oferta”? </li></ul><ul><li>Trivial com WS-*, não-trivial com REST </li></ul><ul><li>Paradigma diferente, modelagem diferente </li></ul>
  19. 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. 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. 21. Fluxo de Processamento <ul><li>Validar URI </li></ul><ul><li>Validar método HTTP </li></ul><ul><li>Obter parâmetros da URI </li></ul><ul><li>Interpretar corpo da requisição </li></ul><ul><li>Processamento do serviço </li></ul><ul><li>Gerar resposta </li></ul>
  22. 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. 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. 24. JAX-RS/Jersey <ul><li>URIs mapeadas em classes/métodos </li></ul><ul><li>Parâmetros extraídos das URIs </li></ul><ul><li>Conversões xml/json/etc -> Java </li></ul><ul><li>Conversões Java -> xml/json/etc </li></ul><ul><li>Manipulação de status/headers HTTP </li></ul>
  25. 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 <ul><li>Uma interface, </li></ul><ul><li>múltiplos formatos </li></ul>
  26. 26. Flexibilidade nas requisições Me diga o que estás mandando Content-Type: text/xml; OU <ul><li>Uma interface, </li></ul><ul><li>múltiplos formatos! </li></ul>charset=UTF-8 Content-Type: application/json; charset=ISO-8859-1 Eu converto e processo
  27. 27. OK, show me the code!!!
  28. 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) <ul><li>UsuarioResource trata de /usuario </li></ul><ul><li>buscarUsuario trata de GET /usuario/{usuarioId} </li></ul><ul><li>Parâmetro usuarioId injetado no método </li></ul>
  29. 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) {} <ul><li>AvaliacaoResource trata de /avaliacao </li></ul><ul><li>avaliarUsuario: </li></ul><ul><li>POST /avaliacao/de/{avaliador}/para/{avaliado} </li></ul><ul><li>2 parâmetros extraídos da URI </li></ul><ul><li>Avaliação consumida do corpo da requisição </li></ul>
  30. 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 ) <ul><li>AvaliacaoResource aceita XML e JSON </li></ul><ul><li>Avaliação em XML/JSON é injetada no método </li></ul><ul><li>Cliente especifica content-type na requisição </li></ul>
  31. 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(); } <ul><li>AvaliacaoResource gera XML ou JSON </li></ul><ul><li>Cliente envia tipo desejado no header Accept </li></ul><ul><li>API fácil para definir corpo e status da resposta </li></ul><ul><li>Diferentes formatos tratados declarativamente </li></ul>
  32. 32. Mapeamento Java <-> XML <ul><li>JAXB é a forma padrão, sempre disponível </li></ul><ul><li>Anotações mapeiam classes e atributos </li></ul><ul><li>Jersey gera JSON a partir do XML gerado </li></ul>@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. 33. Parsing do corpo da requisição <ul><li>Recurso declara formatos esperados </li></ul><ul><li>JAX-RS faz conversões Java <-> diferentes formatos </li></ul><ul><li>E se o corpo da requisição veio inválido? </li></ul><ul><li>Status HTTP 400 – Bad Request </li></ul>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. 34. Clientes Java <ul><li>Requisições HTTP com commons-http-client </li></ul><ul><li>Mapeamento Java/XML e XML/Java com XStream ou JAXB </li></ul><ul><li>Status HTTP é o mais importante </li></ul><ul><li>Alguns headers são importantes também </li></ul>
  35. 35. Exemplo: Avaliação de usuário <ul><li>Obter usuário avaliador e o avaliado </li></ul><ul><li>Obter dados da avaliação </li></ul><ul><li>Montar URI da avaliação </li></ul><ul><li>Gerar corpo da requisição </li></ul><ul><li>Conferir resposta </li></ul>Cliente:
  36. 36. Exemplo: Avaliação de usuário <ul><li>Validar URI + método HTTP </li></ul><ul><li>Parsing da URI para obtenção dos usuários </li></ul><ul><li>Parsing do corpo da requisição </li></ul><ul><li>Chamada ao Service Layer </li></ul><ul><li>Geração da resposta </li></ul>Servidor: <ul><li>Status HTTP da resposta </li></ul><ul><li>Header Location </li></ul><ul><li>RESTFul DSL </li></ul>
  37. 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. 38. Dúvidas comuns <ul><li>Como tratar a paginação de resultados? </li></ul><ul><li>Como implementar links entre recursos? </li></ul><ul><li>Como lidar com acessos concorrentes? </li></ul><ul><li>Como autenticar/autorizar operações? </li></ul>Atom + AtomPub + Apache Abdera <ul><li>Blueprint de implementação REST </li></ul><ul><li>Excelente para conteúdo web </li></ul><ul><li>Google, Microsoft e Globo.com já usam </li></ul>
  39. 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. 40. Conclusão <ul><li>Web services antigamente: </li></ul><ul><li>Troca de performance por interoperabilidade </li></ul><ul><li>Web services atualmente: </li></ul><ul><li>Alta performance E interoperabilidade </li></ul><ul><li>Flexibilidade absoluta </li></ul><ul><li>Web services no futuro: </li></ul><ul><li>Forma padrão de comunicação? </li></ul><ul><li>REST everywhere </li></ul>
  41. 41. Dúvidas??
  42. 42. Quer conhecer mais? JM 56 (REST) – Abril/2008 JM 60 (JAX-RS/Jersey) – Agosto/2008
  43. 43. Contato [email_address] http://brunopereira.org

×