REST - padrões e melhores práticas

2.833 visualizações

Publicada em

Apresentação de Alessandro Oliveira e Felipe Firmo no Oracle Open World/Java One.

Publicada em: Tecnologia
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
2.833
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1.403
Ações
Compartilhamentos
0
Downloads
47
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

REST - padrões e melhores práticas

  1. 1. [ Empowering Business. Architecting IT ]1 © Copyright | www.sensedia.com
  2. 2. REST: Padrões & Melhores Práticas2 © Copyright | www.sensedia.com
  3. 3. Quem somos nós alessandro.oliveira@sensedia.com @aro1976 felipe.firmo@sensedia.com @felipe_firmo3 © Copyright | www.sensedia.com
  4. 4. Público Alvo API Designer Diretor Arquiteto Gerente Programador4 © Copyright | www.sensedia.com
  5. 5. Agenda • Sobre a Sensedia • SOAP vs. REST • Elegibilidade de REST • Desafios de REST • Padrões e Melhores Práticas REST • Ferramentas • Q&A5 © Copyright | www.sensedia.com
  6. 6. [ Sobre a Sensedia ] Nosso core é Arquitetura de TI: Serviços & Ferramentas. Ajudamos empresas a serem Mais Ágeis, Flexíveis e Inovadoras Crescimento consistente: 63% CAGR 2007-20116 © Copyright | www.sensedia.com
  7. 7. [ Sobre a Sensedia ] Profundo conhecimento em: √ SOA (Service Oriented Architechture) √ Governança √ Enterprise Architecture √ Cloud Computing7 © Copyright | www.sensedia.com
  8. 8. [ Sobre a Sensedia ] Posicionado como Visionário no Quadrante Mágico do Gartner(1) Criada a partir de iniciativa conjunta entre Ci&T e Laboratório de Inovação da Unicamp.8 © Copyright | www.sensedia.com
  9. 9. [ Sobre a Sensedia ] Sede em Campinas, SP e escritórios em São Paulo, SP e Philadelphia, EUA Campinas, BR São Paulo, BR Philadelphia, EUA9 © Copyright | www.sensedia.com
  10. 10. [ Quem tem experimentado a proposta de valor da Sensedia ]10 © Copyright | www.sensedia.com
  11. 11. SOAP vs. REST11 © Copyright | www.sensedia.com
  12. 12. SOAP vs. REST • SOAP: Simple Object Access Protocol • Baseado em XML • Padronizado pelo W3C • Soluções de diversos fabricantes • Compatibilidade com diversas linguagens e plataformas • Maior consumo de banda e complexidade na implementação • Contratos fortemente tipados • JSR 224: JavaTM API for XML-Based Web Services (JAX-WS) 2.012 © Copyright | www.sensedia.com
  13. 13. Exemplo de Requisição SOAP POST /Stock HTTP/1.1 Host: www.stockexchange.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: 299 SOAPAction: "http://www.w3.org/2003/05/soap-envelope" <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header> </soap:Header> <soap:Body> <m:GetStockPrice xmlns:m="http://www.stockexchange.org/stock"> <m:StockName>ORCL</m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope>13 © Copyright | www.sensedia.com
  14. 14. SOAP vs. REST • REST: REpresentational State Transfer • É um estilo arquitetural, portanto, não necessariamente um PADRÃO • Fortemente baseado na semantica do HTTP  Operações: GET, POST, PUT, PATCH, DELETE • Virtualmente suportado por qualquer cliente HTTP  Hypertext Transfer Protocol HTTP 1.1 - http://tools.ietf.org/html/rfc2616  PATCH Method for HTTP - http://tools.ietf.org/html/rfc5789 • Menor consumo de banda e overhead de processamento • Contratos Fracos14 © Copyright | www.sensedia.com
  15. 15. Exemplo de uma requisição REST GET /stocks?name=ORCL HTTP/1.115 © Copyright | www.sensedia.com
  16. 16. Desafios REST16 © Copyright | www.sensedia.com
  17. 17. Desafios REST • Talvez o REST como um estilo arquitetural seja MUITO ABSTRATO • Padronização é necessária? • Os designers de API podem utilizar diversas abordagens para cada tema • Cada opção possui prós e contras, que precisam ser ponderados durante a fase de design • A governança pode se tornar muito complexa17 © Copyright | www.sensedia.com
  18. 18. Elegibilidade REST18 © Copyright | www.sensedia.com
  19. 19. Elegibilidade REST vs. SOAP Aspect SOAP REST Público Alvo Interno/Parceiros Qualquer Um Volume de Processamento Moderado Alto, com Picos Transação Distribuida / Orquestração WS-* / BPEL Não Padronizado Semântica de Consistência de Dados Comumente ACID Comumente Eventual Contratos Fortemente Tipados Yes / WSDL / XSD WADL? / Não Padronizado Segurança Basic / Digest / Basic / Digest / WS-Security OAuth / OpenID Ferramentas Automatizadas Bastante maduras Não são maduras Suporte de Linguagens de Programação Boa Excelente Interoperabilidade entre implementações Bastante maduras Não são maduras19 © Copyright | www.sensedia.com
  20. 20. Padrões REST20 © Copyright | www.sensedia.com
  21. 21. Grupos dos Padrões REST • Estratégia de Implementação • Segurança • Formato de Dados • Respostas Parciais • Design21 © Copyright | www.sensedia.com
  22. 22. Estratégia de Implementação • Construir tudo do zero • Reutilizar o legado22 © Copyright | www.sensedia.com
  23. 23. Construir Tudo do Zero • Cenário  Infraestrutura atual inexistente ou obsoleta • Solução  Criação de uma arquitetura de referência  Avaliar a utilização de diversos tipos de banco de dados  Utilização de cache distribuído  Utilização de JMS para operações assíncronas • Impactos  Necessária a avaliação de diversas opções  Análise de impacto de cada escolha23 © Copyright | www.sensedia.com
  24. 24. Reutilizar o Legado • Cenário  Já existem sistemas que provem todas as informações a serem publicadas • Solução  Modificação da arquitetura de referência atual para acomodar novos requisitos  Utilização de JMS para operações assíncronas • Impactos  Risco de sobrecarga nos sistemas legados  Menor flexibilidade no design da solução  Maior latência em consultas24 © Copyright | www.sensedia.com
  25. 25. Segurança • Recurso Público • Autenticação no Recurso • Autenticação por Terceiros • Autorização pelo Recurso • Autorização Centralizada • Criptografia das Requisições/Respostas • Criptografia do Canal25 © Copyright | www.sensedia.com
  26. 26. Autenticação no Recurso • Cenário Usuário  Restrição de acesso a um conjunto Identificado de usuários conhecidos • Solução  Utilizar uma base LDAP, SQL, Recurso chave/valor  Criptografia de senhas usando JavaEE Container algoritmos one-way usando salt • Impactos JAAS  Risco na proteção da base de senhas  Overhead na autenticação LDAP26 © Copyright | www.sensedia.com
  27. 27. Autenticação por Terceiros • Cenário Usuário  Usuários não são conhecidos Identificado previamente pelo recurso  Informações de identidade são de propriedade de terceiros Resource Facebook • Solução Owner  Configurar autenticação utilizando plataforma de terceiros, tais como: – Facebook Recurso API – Twitter • Impactos  Dependência de fatores externos Base de Usuários27 © Copyright | www.sensedia.com
  28. 28. Segurança autenticação por terceiros Referência: https://developers.facebook.com/docs/concepts/login/login-architecture/28 © Copyright | www.sensedia.com
  29. 29. Formato de Dados • Versionamento de Recursos • Multiplos formatos29 © Copyright | www.sensedia.com
  30. 30. Versionamento de Recursos • Cenário  É necessário fazer alterações /pedidos incompatíveis no recurso  Não é possível assegurar a migração de todos os clientes ao mesmo tempo • Solução V 1.0 V 2.0  Manter por um período determinado mais de uma versão do recurso em operação V 1.1 • Impactos  Complexidade de Governança  Aumento de custos de operação e desenvolvimento30 © Copyright | www.sensedia.com
  31. 31. Versionamento de Recursos • Nenhum Versionamento  Funciona como se o recurso /pedidos estivesse sempre na versão 1  Impede a inclusão de novos atributos obrigatórios V 1.0  Impede a retirada de atributos  Tende a deixar os recursos V 1.1 muito complexos  Ao longo do tempo pode ser insustentável V 1.2 Versão Única31 © Copyright | www.sensedia.com
  32. 32. Versionamento de Recursos • Versionamento na URI /pedidos  Ex: http://api.sensedia.com/v1/pedidos  Viola HATEOAS  Fácil roteamento entre servidores /v1/pedidos /v2/pedidos  Fácil manutenção de código  Não requer a utilização de cabeçalhos32 © Copyright | www.sensedia.com
  33. 33. Versionamento de Recursos • Versionamento na Query String /pedidos  Ex: http://api.sensedia.com/pedidos?_version=1  Viola HATEOAS  Parâmetro é opcional ou obrigatório? /pedidos? /pedidos?  Difícil manutenção de código _version=1 _version=2  Não requer a utilização de cabeçalhos33 © Copyright | www.sensedia.com
  34. 34. Versionamento de Recursos • Versionamento no Media Type  Ex: http://api.sensedia.com/pedidos – Accepts: vnd.sensedia.com.pedidos+json; version=1  Dificulta a implementação de clientes  Dificulta o acesso via browser (não deve ter versão default, certo?)  Moderada complexidade na manutenção de código34 © Copyright | www.sensedia.com
  35. 35. Versionamento de Recursos Nenhum URI Query String VND Twitter até 2009 Twitter após 2009 Facebook Azure Flickr Foursquare Google Data GitHub (v 3) Dropbox Netflix * GitHub (v 2) PayPal Yammer EBay Delicious Last FM Twillio35 © Copyright | www.sensedia.com
  36. 36. Múltiplos Formatos • Cenário  Dependendo do recurso, talvez seja /pedidos/ABCD-1234 importante representá-lo de diversas formas. • Solução  Possibilitar que o cliente passe no JSON XML header Accept, o formato desejado.  Prover diversas alternativas de renderização dependendo do tipo do recurso ICAL PDF • Impactos  Flexibilidade do uso pelos clientes  Aumento de complexidade na implementação36 © Copyright | www.sensedia.com
  37. 37. Respostas Parciais • Paginação de Consultas • Subconjunto de Atributos37 © Copyright | www.sensedia.com
  38. 38. Paginação de Consultas /pedidos • Cenário  Os resultados de pesquisas são muito Cliente Página 1 grandes, sendo desnecessário ou inviável o acesso de uma única vez  Necessário a redução de custos de rede principalmente em mobile Página 2 • Solução  Dividir o conjunto de recursos em páginas minimizando o tamanho de Página 3 cada requisição • Impactos  O sistema provedor das informações precisa suportar paginação Página 4  Necessário a utilização de caches para consultas38 © Copyright | www.sensedia.com
  39. 39. Paginação de Consultas • Sem Paginação  Ex: http://api.sensedia.com/v1/pedidos  Resultados potencialmente muito grandes  Inviável para mobile  Pode demandar muita infraestrutura de rede  Simples para implementar, independente da estratégia de implementação utilizada39 © Copyright | www.sensedia.com
  40. 40. Paginação de Consultas • Paginação na URI – Ex 1: http://api.sensedia.com/v1/pedidos/3/50 » Página 3 com 50 registros – Ex 2: http://api.sensedia.com/v1/pedidos/3 » Página 3 – Confunde com a URI para acesso a um elemento do conjunto: » http://api.sensedia.com/v1/pedidos/ABCD-1234540 © Copyright | www.sensedia.com
  41. 41. Paginação de Consultas • Paginação na Query String – Ex: http://api.sensedia.com/v1/pedidos?_pagina=3&_tamanho=50 – Flexível pois o cliente pode ou não utilizar esse recurso – Pode definir o tamanho da página que é mais adequado para o consumo – Query String => Restrições – Opção recomendada para uso geral41 © Copyright | www.sensedia.com
  42. 42. Paginação de Consultas: Cases Query String • Facebook • Twitter  Offset Based  Time Based – Limit – Until – Offset – Count  Time Based – Until  Cursor Based – Since – Since_id – Limit – Max_id  Cursor Based – Count – Limit – Before – After Referência: https://developers.facebook.com/docs/reference/api/pagination/42 https://dev.twitter.com/docs/api/1.1/get/search/tweets © Copyright | www.sensedia.com
  43. 43. Paginação de Consultas • Paginação usando HTTP Headers – Ex: http://api.sensedia.com/v1/pedidos – Requer uso do cabeçalho Range na requisição » Range: pagina=3/50 – Na resposta pode ser utilizado: » Content-Range: pagina=3/50 – Dificulta o uso no browser – Dificulta configuração HTTP Cache – Mantém a QueryString livre de metadados43 © Copyright | www.sensedia.com
  44. 44. Subconjunto de Atributos Exemplo Filtro Positivo: http://api.sensedia.com/v1/pedidos?_atributos=cliente,data,status,total [{ “cliente”: { “codigo”: “ABCD-1234” }, “data”:"2012-10-09T01:01:01", "status": "AGUARDANDO_PAGAMENTO", “total”: 9.99 }]44 © Copyright | www.sensedia.com
  45. 45. Subconjunto de Atributos Exemplo Filtro Positivo: http://api.sensedia.com/v1/pedidos?_atributos=codigo,status [{ “codigo”: “ABCD-1234”, "status": "AGUARDANDO_PAGAMENTO” }, { “codigo”: “EFGH-3456”, "status": ”ENTREGUE” }]45 © Copyright | www.sensedia.com
  46. 46. Subconjunto de Atributos Exemplo Filtro Negativo http://api.sensedia.com/v1/pedidos/4780-DEFG?_atributos=!itens { “codigo”:”4780-DEFG”, “cliente”: { “codigo”: “ABCD-1234” }, “data”:"2012-10-09T01:01:01", "status": "AGUARDANDO_PAGAMENTO", “total”: 9.99 }46 © Copyright | www.sensedia.com
  47. 47. Design • Evitar refreshes desnecessários • Referências fracas entre recursos • Contrato Uniforme • Processamento Assíncrono47 © Copyright | www.sensedia.com
  48. 48. Evitar refreshes desnecessários• Cenário GET /v1/pedidos/ABCD-1234 HTTP/1.1  Refreshes desnecessários podem impactar o potencial de escalabilidade da API Cache-Control: max-age=86400  Recursos possuem diferences Etag: 69fafe9b características quanto a volatilidade de { dados “codigo”:”ABCD-1234”,• Solução ”status”:”AGUARDANDO_PAGAMENTO”  Identificar essas características de volatilidade de dados }  Instrumentar os clientes e HTTP caches• Impactos  Maior esforço em tempo de design  Maior esforço na implementação das operações48 © Copyright | www.sensedia.com
  49. 49. Volatilidade de Dados Estavel Muito durante a Estavel sessão Estavel Instável49 © Copyright | www.sensedia.com
  50. 50. Volatilidade de Dados • Categorias • Clientes  Alteração 1 vez ao mês  Alterações somente na  Aceita até 1 semana de sessão defasagem  Não há defasagem • Produtos • Pedidos  Alteração 1 vez por semana  Alterações frequentes  Acetavel até 1 dia de  Não é aceitavel defasagem defasagem50 © Copyright | www.sensedia.com
  51. 51. Evitar Refreshes Desnecessários • Definir HTTP Headers (na resposta):  Last-Modified: http://tools.ietf.org/html/rfc2616#section-13.3.1  Cache-Control: http://tools.ietf.org/html/rfc2616#section-14.9  ETag: http://tools.ietf.org/html/rfc2616#section-13.3.251 © Copyright | www.sensedia.com
  52. 52. Referências fracas entre recursos• Cenário  Todos os recursos estão de certa forma associados Clientes Pedidos  Não é possível manipular todos os recursos de uma só vez• Solução  Análise do modelo conceitual para Categorias Produtos identificar as composições  Agrupar as composições em um único recurso  Definir associação fraca entre recursos• Impactos  Possibilita a instrumentação de caches de forma mais efetiva52 © Copyright | www.sensedia.com
  53. 53. Referências fracas entre recursos Referências Fortes Referências Fracas53 © Copyright | www.sensedia.com
  54. 54. Referências fracas entre recursos Produto: Categoria: { { “codigo”:”ABCD-1234”, “codigo”:”EFGH-5678”, “descricao”:”…”, “nome”:”smartphones” “preco”: 10.00, } “categoria”: { “codigo”:”EFGH- 5678” } }54 © Copyright | www.sensedia.com
  55. 55. Referências fracas entre recursos - URIs • /categorias • /categorias/{codigo} • /produtos • /produtos/{codigo} • /clientes • /clientes/{codigo} • /clientes/{codigo}/enderecos • /clientes/{codigo}/enderecos/{codigo} • /pedidos • /pedidos/{codigo} • /pedidos/{codigo}/itens • /pedidos/{codigo}/itens/{codigo}55 © Copyright | www.sensedia.com
  56. 56. Contrato Uniforme• Cenário POST /pedidos HTTP/1.1  A manipulação dos recursos devem se comportar de forma idêntica• Solução  Definir quais as operações HTTP serão aceitas 201 500  Definir um cojunto de códigos de retorno de sucesso e erro padronizados  Revisar o comportamento de todos os recursos 401 403• Impactos  Aumento no custo de desenvolvimento inicial  Redução de complexidade no consumo dos recursos56 © Copyright | www.sensedia.com
  57. 57. HTTP Status Codes – Casos de Sucesso 200 OK: aceito para GET 201 Created: aceito para POST, indica que o recurso foi criado com sucesso, deverá existir o header Location: indicando a URI do novo recurso. 202 Accepted: aceito para POST, PUT, PATCH e DELETE, indica que o recurso criado representa um processo assíncrono, portanto, além do header Location, deverá retornar o conteúdo com um atributo status. Posteriormente o recurso poderá ser consultado para avaliar a alteração do status. 204 No Content: aceito para PUT, PATCH e DELETE57 © Copyright | www.sensedia.com
  58. 58. HTTP Status Codes – Casos de Erro • Exceção de negócio – retorna código 422; • Exceção do cliente – família 400:  400 - Requisição Mal Formada;  401 - Requisição Requer Autenticação;  403 - Requisição Negada;  404 - Recurso não Encontrado;  405 - Método não Permitido; • Exceção do Servidor – retorna código 500; Além do código de retorno http, os detalhes do erro devem ser retornados no payload, com um link para a documentação do erro;58 © Copyright | www.sensedia.com
  59. 59. Processamento Assíncrono• Cenário  As operações que modificam o estado, POST, PUT, PATCH e DELETE podem demorar, principalmente quando dependem do legado• Solução  Armazenar a requisição de forma imediata  Retornar para o cliente com um ticket para que ele possa consultar o status posteriormente  Notificação de alteração de estado• Impactos  Maior complexidade na implementação do59 cliente e do recurso © Copyright | www.sensedia.com
  60. 60. Processamento Síncrono60 © Copyright | www.sensedia.com
  61. 61. Recursos com Processamento Assíncrono • São recursos que representam (ou iniciam) a execução de processos de longa duração. • Na criação de um novo recurso, deverá retornar o código 202 – Requisição Aceita • Eventuais erros de negócio deverão ser representados na forma de “status”, que poderão ser consultados de forma subsequente. • Notificação de Fim de Trabalho:  Dispositivos Móveis e Desktops: Polling  Outros Sistemas: Notificação de Eventos61 © Copyright | www.sensedia.com
  62. 62. Processamento Assíncrono - Polling62 © Copyright | www.sensedia.com
  63. 63. Processamento Assíncrono - Callback63 © Copyright | www.sensedia.com
  64. 64. Ferramentas64 © Copyright | www.sensedia.com
  65. 65. [ Componentes Tecnológicos ]Partners Apps / Commerce REST API Traffic API Internal Call Business Application 1 ESB Platforms Gateway Business Application 2 Monitoring Internal Services Control API Traffic Policy Discovery Deploy Publish Developers Web Browser Partners API Portal Get API Usage Manager Engage Developers Manage API documentation, Access Keys and Usage
  66. 66. Q&A66 © Copyright | www.sensedia.com
  67. 67. Contatos alessandro.oliveira@sensedia.com @aro1976 felipe.firmo@sensedia.com @felipe_firmo67 © Copyright | www.sensedia.com
  68. 68. Thank You! [ Empowering Business. Architecting IT ]68 © Copyright | www.sensedia.com

×