Na última década, todo desenvolvedor de aplicativos da web se tornou um designer de API. Mas a maioria das organizações não pensa nos desenvolvedores como designers de API, nem pensa nas APIs como um produto de design — em detrimento da produtividade de seus desenvolvedores. Com o surgimento da IA, há mais APIs do que nunca, tornando esse problema ainda pior.
Neste artigo, falarei sobre as APIs internas frequentemente negligenciadas que, cada vez mais, acidentalmente alimentam os negócios e como as organizações podem voltar a controlar essas APIs.
As APIs (internas) que acidentalmente alimentam os negócios
As APIs que geralmente chamam a atenção são as APIs nas quais as organizações construíram intencionalmente seus negócios. Essas são APIs como a Stripe API, a Twilio API e a Instagram API — APIs que são cruciais para as estratégias de produtos e entrada no mercado das empresas. Essas APIs começam com designs bem revisados e passam por muitas iterações de polimento, curadoria e documentação antes de chegarem ao seu consumidor, o público.
Depois, há as APIs nas quais as organizações acidentalmente construíram seus negócios:
APIs front-end e back-end
A ascensão do design de API RESTful desde o início dos anos 2000 significa que os front ends de aplicativos da web conversam principalmente com os back ends por meio de APIs.
APIs de serviços cruzados
A ascensão das arquiteturas orientadas a serviços desde o início dos anos 2000 significa que as organizações de software são estruturadas de forma que cada equipe possua um conjunto de serviços. Essas equipes operam de forma cada vez mais descentralizada, com equipes individuais projetando suas próprias APIs, em vez de um pequeno número de arquitetos projetando todas as APIs de cima para baixo. Geralmente, há mais desses tipos de APIs do que APIs externas. Essas APIs internas geralmente são projetadas e de propriedade integral de desenvolvedores.
Por que o design é importante para APIs internas
Ok, você pode estar se perguntando. O que importa que os desenvolvedores estejam projetando APIs que usuários externos nunca viram? Gerentes de produto e donos de negócios nunca se aprofundaram no código, então eles realmente precisam se aprofundar em APIs internas?
A questão em questão é que as decisões de design orientadas pelo desenvolvedor afetam tanto a capacidade de entregar uma boa experiência do usuário quanto a velocidade do desenvolvimento (e, portanto, a agilidade do negócio). E há uma tensão entre essas duas preocupações.
Da perspectiva de um usuário de API, o design de API ideal tem as funções mais gerais possíveis. Por exemplo, se você estiver usando uma API de banco, o ideal é que haja apenas uma função para obter o saldo de um usuário, uma função para alterar o saldo, etc. Se houver dezenas de funções para chamar para obter um saldo bancário, fica muito mais fácil chamar a errada!
Da perspectiva de um desenvolvedor, no entanto, a API mais fácil de construir é a mais específica . Isso ocorre porque quanto mais específica for uma função, mais um desenvolvedor pode otimizar. Por exemplo, a maneira de construir o aplicativo bancário mais rápido possível é fazer com que o backend do aplicativo envie exatamente as informações certas que o frontend do aplicativo precisa e nada mais. APIs internas tendem a desempenho, o que significa que são projetadas pelo desenvolvedor para facilitar a otimização, em vez de para facilitar o consumo.
Na ausência de outras forças, os desenvolvedores tenderão a oferecer uma boa experiência imediata ao usuário, em vez de buscar uma velocidade de desenvolvimento de longo prazo ou mesmo a reutilização de uma API para fins de plataforma.
Aproveite o poder do design orientado ao desenvolvedor
Há duas maneiras de olhar para o mundo das APIs em que vivemos atualmente. Se olharmos para esse mundo pela ótica do design de APIs de cima para baixo, podemos lamentar o caos e a proliferação de APIs que se abateram sobre nós e continuar tentando assumir o controle priorizando as especificações.
Mas há uma alternativa mais empoderadora, uma em que aceitamos a natureza orientada pelo desenvolvedor do design de API e abraçamos a colaboração. O design de API não precisa ser totalmente de cima para baixo, orientado pelo arquiteto ou de baixo para cima determinado pelo desenvolvedor. E se o design de API fosse, em vez disso, uma colaboração?
Aqui está um modelo de como é o design de API colaborativa em um modelo que prioriza o desenvolvedor:
Um desenvolvedor de API projeta uma API interna para um propósito específico, obtendo feedback do consumidor imediato e do colega desenvolvedor de API. Esses designs não são apenas documentação estática, mas podem ser aprimorados com informações mais ricas de testes ou simulações.
À medida que a API é mais utilizada, o desenvolvedor recebe mais feedback e atualiza a API. Versões anteriores da API são armazenadas e documentadas; os motivos para atualizar a API são claros para todos. A API evolui em conjunto com um "design vivo", permitindo que os desenvolvedores mantenham a implementação da API otimizada para os casos de uso atuais, permitindo que os consumidores usem a API sem problemas para suas necessidades e permitindo que consumidores e colaboradores forneçam feedback conforme suas necessidades mudam.
Bônus: o design vivo é atualizado automaticamente conforme a implementação é atualizada, usando o comportamento real do aplicativo como fonte de verdade. Ao tornar todo o desenvolvimento de software em desenvolvimento de API, você desbloqueia uma quantidade imensa de produtividade — mas somente se for tão fácil compartilhar designs de API quanto é compartilhar código e documentos.
É incrível o quanto mais rápido as organizações de software podem se mover quando capacitam os desenvolvedores a construir APIs de forma descentralizada. O desenvolvimento rápido e descentralizado não requer sacrificar a organização ou a coordenação. A chave é a colaboração produtiva.
