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.

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.