Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Existe Vida Além do REST?

Existe Vida Além do REST?

Construir uma API pode parecer simples. Transformar models em JSON, uma forma de autenticação e pronto, temos uma "API". O padrão REST é adotado como solução na maioria das vezes, mas, sem o conhecimento adequado, o design de uma API pode ficar confuso e despadronizado, dificultando a utilização dos usuários. Além disso, outras tecnologias fornecem soluções diferentes para problemas encontrados durante a concepção e/ou consumo de uma API. Essa talk analisa o REST e outras tecnologias com exemplos para que você entenda seus usuários e tome a decisão certa para sua API.

Db982994346dad910547a7c62a90dadd?s=128

Ravan Scafi

March 28, 2017
Tweet

More Decks by Ravan Scafi

Other Decks in Technology

Transcript

  1. Existe vida além do REST ?

  2. GET /whoami Ravan Scafi Back-end Developer na Leroy Merlin Brasil

    Co-organizador do Meetup do Laravel SP @ravanscafi
  3. API? O que é uma API?

  4. Interface é um elemento que proporciona uma ligação física ou

    lógica entre dois sistemas ou partes de um sistema que não poderiam ser conectados diretamente.
  5. Parte 1 Recursos vs Operações

  6. Quando Pensamos em APIs...

  7. REST REpresentational State Transfer

  8. REST Baseado em Endpoints GET /api/users/rscafi HTTP/1.1 Host: meusite.dev

  9. GET /api/users/rscafi HTTP/1.1 Host: meusite.dev REST Separado por Recursos (Substantivos)

  10. GET /api/users/rscafi HTTP/1.1 Host: meusite.dev REST Verbos HTTP indicam a

    ação
  11. REST Relação Cliente-Servidor

  12. REST Segue convenções HTTP

  13. REST Controle por Hypermedia (HATEOAS - RMM)

  14. GET /api/users/rscafi HTTP/1.1 Host: meusite.dev { "id": "rscafi", "name": "Ravan

    Scafi", "website": "http://ravan.me", "_links": { "self": { "href": "http://meusite.dev/api/users/rscafi" } } }
  15. REST Endpoints cacheáveis

  16. REST Uniforme

  17. REST Feito para durar décadas

  18. Problemas (Spoiler: Parte 1!) REST

  19. REST - Problemas Recomendações nem sempre são seguidas

  20. REST - Problemas Excesso de Roundtrips dependendo da operação

  21. REST - Problemas Nem sempre os Verbos HTTP disponíveis falam

    com clareza
  22. Exemplo - Slack Um usuário pode ser “kickado”, “banido” ou

    pode “deixar” um canal
  23. Exemplo - Slack DELETE /users/rscafi HTTP/1.1 Host: api.slack.com

  24. Exemplo - Slack DELETE /users/rscafi HTTP/1.1 Host: api.slack.com Content-Type: application/json

    {“status”: “kicked”}
  25. Exemplo - Slack DELETE /users/rscafi HTTP/1.1 Host: api.slack.com Content-Type: application/json

    {“status”: “kicked”, “kick_channel”: “random”}
  26. Exemplo - Slack DELETE /channels/random/users/rscafi HTTP/1.1 Host: api.slack.com

  27. Exemplo - Slack DELETE /channels/random/users/rscafi HTTP/1.1 Host: api.slack.com Content-Type: application/json

    {“status”: “kicked”}
  28. REST - Problemas Operações “BULK” fogem do Padrão

  29. O que fazer? ?

  30. RPC Remote Procedure Call !

  31. RPC Baseado em Endpoints GET /api/getUser HTTP/1.1 Host: meusite.dev Content-Type:

    application/json {“id”: “rscafi”}
  32. GET /api/getUser HTTP/1.1 Host: meusite.dev Content-Type: application/json {“id”: “rscafi”} RPC

    Similar à chamada de funções
  33. “Equivalência” em PHP <?php // definição function getUser ($id) {

    // } // chamada getUser('rscafi');
  34. RPC Popularizado pelo SOAP (Simple Object Access Protocol)

  35. SOAP - Exemplo <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <soapenv:Header> <ns1:RequestHeader soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next" soapenv:mustUnderstand="0" xmlns:ns1="https://www.google.com/apis/ads/publisher/v201605"> <ns1:networkCode>123456</ns1:networkCode> <ns1:applicationName>DfpApi-Java-2.1.0-dfp_test</ns1:applicationName> </ns1:RequestHeader> </soapenv:Header> <soapenv:Body> <getAdUnitsByStatement xmlns="https://www.google.com/apis/ads/publisher/v201605"> <filterStatement> <query>WHERE parentId IS NULL LIMIT 500</query> </filterStatement> </getAdUnitsByStatement> </soapenv:Body> </soapenv:Envelope>
  36. RPC Porém o SOAP perdeu espaço para as APIs REST

  37. REST - Exemplo GET /ads?parentId=null&limit=500 HTTP/1.1 HOST: api.example.com

  38. RPC Mas não existe somente o SOAP!

  39. RPC baseado em JSON - Exemplo POST /getAdUnitsByStatement HTTP/1.1 HOST:

    api.example.com Content-Type: application/json {"filter": "WHERE parentId IS NULL LIMIT 500"}
  40. RPC Foco em Operações

  41. Exemplo - Slack POST /api/channels.kick HTTP/1.1 Host: slack.com Content-Type: application/json

    { "token": "xxxx-xxxxxxxxx-xxxx", "channel": "random", "user": "rscafi" }
  42. RPC Relação entre (Micro) Serviços

  43. RPC A partir de uma Definição de serviços, código é

    gerado
  44. RPC Complexidade Abstraída

  45. 10.000.000.000 de chamadas RPC POR SEGUNDO! Google

  46. gRPC Framework “universal”, open source e performático

  47. gRPC HTTP/2

  48. gRPC Protocol Buffers

  49. gRPC Linguagem de Definição de Serviços

  50. gRPC service Greeter { rpc SayHello (HelloRequest) returns (HelloReply) {}

    } message HelloRequest { string name = 1; } message HelloReply { string message = 1; }
  51. gRPC Gera código para as maiores linguagens

  52. gRPC protoc --proto_path=examples/protos \ --php_out=examples/php \ --grpc_out=examples/php \ --plugin=protoc-gen-grpc=bins/opt/grpc_php_plugin \

    ./examples/protos/helloworld.proto
  53. gRPC Cria stubs de Classes, onde os métodos correspondem a

    uma rota RPC
  54. gRPC $request = new Helloworld\HelloRequest(); $request->setName($name); list($reply, $status) = $client->SayHello($request)->wait();

    $message = $reply->getMessage();
  55. Problemas RPC

  56. RPC - Problemas Abstrai complexidade (!)

  57. RPC - Problemas Pode complicar mais do que se não

    estivesse presente
  58. REST vs RPC Foco Complexidade Comunicação REST Recursos Exposta Sistemas

    RPC Operações Abstraída Serviços
  59. Parte 2 Clientes

  60. Quem vai consumir esses dados?

  61. API

  62. API

  63. API

  64. Como evitar isso?

  65. BFF Backend For Frontend

  66. BFF Abordagem criada pelo SoundCloud

  67. BFF Clientes da API eram muito diferentes entre si

  68. Clientes do SoundCloud Web Mobile Parceiros

  69. BFF Cada equipe mantém uma API para atender às suas

    necessidades
  70. BFF Menos burocracia para evoluir as APIs

  71. API Monstro Web API Mobile API SoundCloud’ BFFs

  72. Problemas BFF

  73. APIs fragmentadas e em linguagens diferentes BFF - Problemas

  74. Código duplicado! BFF - Problemas

  75. Maior complexidade por cliente BFF - Problemas

  76. Mas e o REST? Então é ele o problema?

  77. API Geral Android API Web API iOS API Netflix’ API

    Gateway (existe o Zuul na frente, mas isso é tema pra outra talk)
  78. Até funciona, mas...

  79. Problemas Parte 2 REST

  80. REST - Problemas Includes vs Endpoints em recursos relacionados

  81. REST - Problemas Overfetching / Underfetching

  82. REST - Problemas HATEOAS não diz nada sobre formato de

    Requisições e Respostas
  83. REST - Problemas Não possui uma Especificação formal

  84. REST - Problemas API pode rapidamente ficar gigantesca para atender

    a todos os clientes
  85. REST - Problemas É difícil evoluir os dados sem saber

    o que os clientes de fato consomem
  86. REST - Problemas Quanto mais complexa a API fica, menos

    eficaz é o Cache
  87. GraphQL Graph Query Language

  88. GraphQL Queries + Mutations + Documentação

  89. GraphQL Única rota servindo de “tunel” para as queries

  90. GraphQL POST /graphql HTTP/1.1 Host: meusite.dev Content-Type: application/graphql { users

    { name } }
  91. GraphQL Dados da API são descritos

  92. GraphQL type User { name: String website: String hobbies: [Hobby]

    }
  93. GraphQL Um Request pede por dados específicos

  94. { user(name: "Ravan Scafi") { website, hobbies { name }

    } }
  95. GraphQL O retorno é exatamente o que foi requisitado

  96. { "user": { "website": "http://ravan.me", "hobbies": [ {"name": "PHP"}, {"name":

    "Viajar"} ] } }
  97. GraphiQL

  98. GraphQL Mutations enviam dados para o servidor

  99. GraphQL Especificação “completa” e documentada

  100. GraphQL Dados podem evoluir com (maior) facilidade

  101. Problemas (achou que tinha bala de prata?) GraphQL

  102. GraphQL - Problemas Técnicas de cache são difíceis

  103. GraphQL - Problemas Implementação pode ser complexa

  104. GraphQL - Problemas Próprias (e novas) convenções

  105. GraphQL - Problemas Upload de arquivos é “hacky”

  106. REST vs GraphQL Foco Implementação Clientes Cache REST Resiliência Evolutiva

    Parecidos Robusto GraphQL Performance Deve atender a especificação Diferentes Difícil
  107. Conclusões

  108. REST Atende bem em CRUDs e onde as convenções HTTP

    possam ser aplicadas.
  109. RPC Atende bem entre serviços e quando o foco é

    em operações.
  110. GraphQL Garante performance de Clientes e permite evolução mais rápida.

  111. Dicas de Ouro

  112. Você pode usar mais de uma solução!

  113. (mas Por favor, não na mesma API)

  114. Versionamento é sempre difícil

  115. Não existe bala de prata.

  116. Entenda seus dados e seus Usuários/Clientes

  117. Empatia é a chave

  118. Empatia é a capacidade de se identificar com outra pessoa,

    de sentir o que ela sente, de querer o que ela quer, de apreender do modo como ela apreende etc.
  119. Obrigado! @ravanscafi

  120. Estamos Contratando! Dev BackEnd, Dev FrontEnd, DevOps gguitte@leroymerlin.com.br

  121. Agradecimentos Agradecimentos especiais a todos do SlidesCarnival que fizeram e

    disponibilizaram o template da apresentação gratuitamente.