Olá! Nesse conteúdo vamos aprofundar na abordagem de desenvolvimento API First. Esse método vem ganhando cada vez mais espaço. Em 2021 foi trend topic do mundo de APIs. De acordo com Postman’s State of API Report 2022 as empresas estão investindo pesado, 2/3 das empresas dos mais de 28 mil profissionais de API entrevistados disseram estar investindo em API First.
Contextualizaremos como é definida uma API nos dias de hoje, preocupações na implementação, o que é code first e alguns possíveis problemas que podem surgir utilizando essa abordagem. E então vamos desvendar o que é API First e seus princípios. Também falaremos sobre os benefícios e como planejar essa estratégia. Então se acomodem e venham comigo!
Application Programing Inteface (API)
APIs são interfaces programáveis da aplicação que permitem integrar serviços (sejam eles legados, banco de dados, microsserviços) com aplicações web, mobile ou até mesmo entre os próprios serviços. Em um primeiro momento podemos considerar as APIs como um ativo tecnológico.
Mas nos dias de hoje, com o grande boom de empresas SaaS e receitas por assinatura o mercado ficou muito mais competitivo, pois a migração de um sistema para outro por parte do cliente se tornou fácil e prática. Também existem várias opções no mercado e ele não precisa mais ficar “preso” a determinado fornecedor. Com isso Customer Experience tem papel importante. Pois começa a se pensar mais na experiência do cliente através de estratégias de UX, UI, Customer Success e por aí vai. E por isso as APIs tem um papel essencial, pois elas são a interface programável da sua aplicação, elas são o ativo que expõe seus serviços para os clients. E APIs com uma arquitetura e design bem pensados aceleram parcerias, aumentam conectividade, facilitam integrações e geram mais receita, através de monetização seja ela direta ou indireta. Sendo assim, podemos entender que as APIs não são apenas um ativo tecnológico, e sim um ativo de negócio, muitas vezes sendo o produto em si, que é o que chamamos de api-as-a-product.
Preocupações na Implementação de uma API
Na implementação existem diversas preocupações. Como manter uma documentação independente, ou seja, ativa, transparente e auto-descritiva. Como definir um modelo padrão a ser seguido, pois podem acontecer desenvolvimentos em paralelo, sendo necessário padronização para facilitar a governança. O quanto a API pode fazer mais (extensibilidade) sem perder consistência. O quanto de manutenção ela pode gerar (manutenibilidade) e claro, como reutiliza-la. Pois se a API não tem uma documentação auto-descritiva, se elas não são padronizadas, extensíveis e geram muito manutenção, dificilmente será reutilizada. Podendo trazer retrabalho, que demandará tempo. E como sabem, “tempo é dinheiro”!
Então documentação, padronização, extensibilidade, consistência, manutenibilidade e reuso são geralmente as principais preocupações que surgem na implementação de uma API.
Code First
É uma abordagem de desenvolvimento focada no domínio da aplicação. Geralmente se inicia pela criação das classes, modelagem do banco de dados e depois a integração (API).
O grande problema nesse tipo de abordagem é que ela não é desenvolvida pensando em quem vai consumir. Com isso, o frontend precisa esperar que o backend esteja pronto. Geralmente o contrato (swagger) é gerado automaticamente a partir do código, ocasionando inconsistências que devem ser corrigidas, diminuindo a produtividade. Além disso, o fato de se começar pelo código pode fazer com que a API fique fora de sincronia.
Outro problema também é a falta de previsibilidade no design da API, visto que a implementação só iniciará após o backend estar “pronto”.
API First
É uma abordagem de desenvolvimento onde o design da API é priorizado. O intuito é que todas as partes interessadas (stakeholders) participem do processo, fazendo com que a API seja construída de forma colaborativa. Diferente do code first, onde o desenvolvimento se inicia pelo código, com API First Design suas APIs são tratadas como “first-class citizen”, ou seja, o desenvolvimento se inicia pela API.
Essa abordagem tem 3 princípios, são eles:
- Sua API é a primeira interface de usuário da sua aplicação.
- Sua API vem primeiro, depois a implementação.
- Sua API é descritiva (e quase sempre auto-descritiva).
Com isso, entende-se que a preocupação nessa estratégia é garantir a melhor experiência para quem vai consumir. Tratar as APIs como “first-class citizen” quer dizer que estamos garantindo uma ótima UX/UI.
Inclusive, olha o problemão que pode causar um design mal feito. Lembrem-se, publicar uma API é irreversível e consequente (matriz de decisão)!
Benefícios
Redução de custos
Lembrem-se que nessa abordagem de desenvolvimento os stakeholders participam desde o início. Sendo assim, a probabilidade de uma documentação consistente, que esteja de acordo com a necessidade de quem vai consumir a API é extremamente alta, por isso o retrabalho é menor, e consequentemente os custos.
Aumento do time-to-market
Uma API bem documentada, implementada e de fácil utilização pode acelerar os ganhos do negócio. Pois foi concebida pensando em quem vai consumir e muitos desses possivelmente participaram do processo e já podem estar até com a integração desenvolvida parcialmente. E os que não participaram, por terem em mãos uma documentação robusta, podem desenvolver rapidamente as integrações.
Experiência do desenvolvedor melhorada
A documentação facilitará o desenvolvimento, e a disponibilização de mocks para testes trarão uma experimentação acelerada, fazendo com que a experiência do desenvolvedor em todo o processo melhore consideravelmente. E é sobre isso, certo? #dx e #b2d.
Minimização dos riscos de falha
As partes interessadas participaram do processo, desde o momento de concepção, da criação do contrato, até na fase de testes, e com as sugestões de melhoria, correções, para que tudo ajustes sejam feitos em tempo hábil. Com isso, quando a API for implementada, o risco de falha será muito menor, pois as validações são realizadas durante o desenvolvimento, e melhor, com o apoio de quem vai realmente utiliza-la.
Divisão de responsabilidades
Como são vários envolvidos, uma das vantagens é que as responsabilidades serão divididas, facilitando o trabalho de cada um, pois cada um será responsável por fazer exatamente o que deveria. Por exemplo, a pessoa de segurança cuidará de aspectos de segurança, pessoa de backend cuidará dos aspectos de desenvolvimento (código), pessoa de negócio cuidará da parte não-técnica e por aí vai.
Paralelismo de esforços
Com a divisão de responsabilidades temos paralelismo nos esforços. É bem legal pensar que à partir do momento que API está mockada, ou seja, pronta para testes, os desenvolvimentos (tanto do backend quanto do frontend) podem ocorrer em paralelo.
Reuso
Em uma abordagem API First, a API será concebida com as partes interessadas envolvidas, gerando uma documentação robusta e uma API consistente. Com isso, a probabilidade desse mesmo modelo ser reutilizado é muito alta, e com uma API consistente também é possível que, dado o contexto, reutilizemos ela, tornando-a mais extensível.
Planejamento
Não será da noite para o dia que você mudará a forma de desenvolvimento. É necessário planejamento, abaixo um passo-a-passo de como planejar um programa API First Design.
Brainstorm
Primeiro passo é identificar os serviços-chave que o negócio oferece e suas capacidades. Nesse momento é importante a reflexão sobre quais tipos de APIs deveriam ser construídas e que tipos de serviços poderiam ser oferecidos através delas.
Definição dos stakeholders
É de extrema importância a definição das partes interessadas, pois são elas que serão diretamente impactadas no negócio. Definindo-as, o desenvolvimento da API será mais assertivo pois quem consumirá participará de todo o processo, e não só como ouvinte, mas com voz ativa, contribuindo.
Design do contrato da API e criação do style guide
O contrato estabelecerá padrões e boas práticas para o design das APIs. Também é importante que esses padrões e boas práticas estejam descritos de forma clara e transparente (lembrem-se do 3º princípio, documentação auto-descritiva). No style guide é importante que contenham informações sobre como o time fará o design das APIs, status code, versionamento, como lidar com erros e etc. Um style guide garantirá um design padronizado e seguindo as boas práticas.
Definir ferramentas/automações de processos
As ferramentas estão presentes no nosso dia-a-dia justamente para facilitar nosso trabalho. A automação faz parte de qualquer área de qualquer empresa de tecnologia. Algumas com grau maior de automação, outras com grau menor. Mas até que ponto seus processos deveriam ser automatizados? Defina bem o que pode e o que não pode ser automatizado, e atente-se para não cair no possível problema do code first onde contratos geralmente são criados automaticamente à partir do código através de extensões, fazendo com que posteriormente sejam necessários ajustes que poderiam ter sido evitados, podendo trazer retrabalho.
Criação de portal de desenvolvedor
O portal auxiliará os desenvolvedores na degustação e testes através de try it out ou mesmo com disponibilização de SDKs.
Por último mas não menos importante, GOVERNANÇA! É fundamental que se tenha um processo de governança das APIs em qualquer esfera ou etapa. A governança é atemporal, ela fará parte da concepção, criação do contrato, desenvolvimento, testes, implementação, acompanhamento e por aí vai. Ela contempla todo o ciclo de vida das APIs, potencializando e garantindo que o design, criação e implementação estejam de acordo com o esperado. Além do rastreio e monitoramento contínuo para acompanhar a saúde e aderência das APIs.
Espero que tenham curtido. Muito obrigado por você, que leu até aqui!
