[Desenvolvimento] Projetando APIs REST
Sempre que vamos começar um novo projeto, vem aquela velha discussão de começar pela interface, API, funcionalidade (shape up ou mais ágil) ou até pelo banco (galera mais antiga). Bem, cada uma tem suas vantagens e desvantagens já amplamente discutidas por aí. Mas e quando o seu produto é apenas uma API o que acontece?
O problema com o desenvolvimento de serviços que são 100% por API para usuários finais é que geralmente fica muuuito a critério da parte técnica e isso tem alguns problemas. A API pode ficar com muitas abstrações (super simples, mas dificultando utilizações mais avançadas por parte do cliente) ou ela fica extremamente desacoplada (super complexa, com várias etapas até para coisas simples, fazendo com que o cliente precise construir muita coisa em cima) e às vezes com excesso de funcionalidades (que fogem do escopo ou que simplesmente ninguém vai usar, deixando mais trabalho para dar manutenção e podendo até abrir brechas na segurança. Ainda mais quando lançamos novas versões, que faz o que já era esquecido, se perder de vez nas versões anteriores).
Em um primeiro momento pode parecer uma ótima ideia entregar algo super completo, funcionalidades extras ou “complementos” da funcionalidade original. Porém, isto é perigoso, pois a partir do momento que você adiciona diferentes escopos em sua aplicação, mais áreas de conhecimentos começam a ser envolvidas, além de aumentar muito a introdução de bugs, brechas e insatisfações (deixa desperdícios para outro artigo). Por exemplo, um Load Balancing. Pensa como é dar a manutenção em um HAProxy que só faz isso ou em dar manutenção em um NGINX da vida que além de fazer LB faz N coisas a mais, se os seus clientes só precisam de um LB, todos esses outros serviços só o tornaram mais complexos e sem retorno de valor.
Claro que vai muito de produto para produto, a necessidade de entregar algo pronto (abstraído e de fácil utilização) ou dar as ferramentas necessárias para utilização (algo mais desacoplado, fácil de estender e integrar mais funcionalidade). Um bom jeito para encontrar o equilíbrio das coisas é através de personas (mesmo que seu usuário no final do dia muito possivelmente será outro dev, não pode esquecer também do pessoal de negócio que estará na ponta do produto quem estiver construindo). Saber quem é seu cliente (e o produto que irá usufruir da sua API) é essencial para focar em funcionalidades que realmente fazem sentido para ele.
Outro caminho é criar um GUI de exemplo do principal foco do seu produto e suas funcionalidades (se possível) para expor e assim todos os seus potenciais clientes podem ter uma visão real da aplicação funcionando e como suas integrações foram pensadas. Mostrar como as coisas se conversam e de fato funcionando, vale bem mais que explicações e documentos. Também é possível optar por tecnologias mais flexíveis como Graphql para deixar que seus clientes decidam o que vão usar, dando mais liberdade em suas implementações.
Produtos que são totalmente APIs tem outros pontos que precisam de atenção redobrada como cobranças, limitações, personalização, distribuição (como será o acesso a ela), segurança (principalmente, até porque sua API está exposta) e base de dados (como essas informações serão persistidas e os acessos a ela).
Tais reflexões auxiliam também na criação de serviços internos para utilização de outras equipes dentro de uma empresa, pois abre sua mente para diferentes implementações e claro garante uma das maiores vantagens do uso de microsserviços, que é ter equipes totalmente distintas aproveitando funcionalidades existentes. Conclusão de hoje é foco, assim como temos SRP para classes e funções, isso vale muito também para serviços e produtos. Abraços!