A mentalidade da plataforma no gerenciamento de produtos de API

Não é segredo que a pandemia amplificou significativamente a necessidade de as organizações adotarem uma estratégia digital-first. As transformações digitais que haviam sido despriorizadas em favor de outras metas organizacionais mudaram da noite para o dia, com uma urgência sem precedentes. De acordo com uma pesquisa global de executivos da McKinsey de 2020, as empresas aceleraram a taxa de digitalização das operações internas e expandiram os portfólios de produtos digitais em vários anos, apesar dos desafios significativos impostos pelo COVID-19.

No centro dessas transformações digitais está a integração, facilitada por interfaces de programação de aplicativos (APIs). Antes consideradas simplesmente como “mensageiras” ou “intermediárias” que transmitiam dados entre sistemas de software, as APIs agora são reconhecidas como o “tecido conjuntivo” dos ecossistemas digitais, oferecendo integração ilimitada e oportunidades de negócios para as organizações que as constroem e as alavancam. Devido ao potencial único que as APIs representam, os gerentes de produto que supervisionam seu desenvolvimento devem adotar uma abordagem que desbloqueie seu valor latente, que enfatize a flexibilidade e a extensibilidade para garantir experiências de integração perfeitas.

Fazendo mais com menos

Mesmo antes do último ano sem precedentes, o valor das APIs para as organizações já estava bem documentado e a economia das APIs vinha prosperando há algum tempo. Para entender o cenário de integrações de hoje, é útil explorar as origens da filosofia Best of Breed (BoB). Antes da década de 1990, os fornecedores de software comercializavam soluções de pacote de planejamento de recursos empresariais (ERP) que tentavam resolver uma ampla variedade de desafios organizacionais. Cada vez mais, esses conjuntos passaram a ser vistos como complicados e impraticáveis, porque não abordavam casos de uso específicos da organização. Como resultado, os fornecedores começaram a criar ferramentas mais focadas que solucionavam desafios para uma área funcional, em vez de suítes maiores que tentavam fazer tudo para todos. As empresas acolheram a ideia de escolher entre uma variedade de ferramentas menores e mais especializadas e começaram a montar coleções de soluções individuais que melhor correspondiam às suas necessidades específicas.

Ligando os pontos

À medida que a abordagem BoB ganhou força, as integrações tornaram-se uma parte crucial das estratégias de produtos. Uma ferramenta que fosse ótima para resolver problemas para uma área de uma empresa tinha que ser capaz de se integrar bem com outros produtos BoB que provavelmente seriam usados ​​junto com ela. Considere o HubSpot, o software de vendas e CRM implementado por organizações para rastrear e otimizar seus pipelines de vendas e relacionamentos com clientes. O HubSpot se integra prontamente a outros softwares BoB, como DocuSign (assinaturas digitais), Twilio (notificações por e-mail/SMS) e Zendesk (suporte ao cliente) sem exigir desenvolvimento adicional das equipes de engenharia do cliente.

A necessidade de ferramentas complementares para se conectarem perfeitamente umas às outras foi acompanhada por uma mudança em todo o setor para abraçar a abertura em vez de limitar as interações entre os sistemas. Em algum lugar ao longo do caminho, o número de integrações suportadas por um produto tornou-se uma métrica que vale a pena marketing.

A proposta da plataforma

O verdadeiro valor das integrações, no entanto, vai além de sua capacidade de coordenar ferramentas e sistemas distintos. Na melhor das hipóteses, as APIs são o mecanismo coletivo para transformar produtos em plataformas. Produtos, por definição, são ferramentas que possuem uma aplicação específica; daí “aplicativos”. Eles são limitados em sua capacidade de criar múltiplas propostas de valor e, por extensão, múltiplos fluxos de receita. As plataformas, por outro lado, agregam valor de uma maneira diferente: fornecendo a camada de infraestrutura sobre a qual vários produtos podem ser construídos.

As APIs abrem novos canais de negócios ao capitalizar a experiência de terceiros que as utilizam. Os desenvolvedores consumidores podem criar um aplicativo imobiliário que usa as APIs Places do Google Maps para ajudar os usuários a procurar uma casa, ou podem aproveitar as APIs de voo do Skyscanner e as APIs de hotel da Expedia para criar um site de ecoturismo especializado em viagens para um local específico. Esses desenvolvedores e parceiros externos se beneficiam ao obter acesso a dados e serviços existentes que podem adaptar para seus negócios, e proprietários de APIs como a Expedia expandem seu alcance e monetizam oportunidades que não existiriam se continuassem, digamos, apenas listando hotéis em seus produtos.

Tornando-o modular

Para os líderes de produtos, desenvolver uma estratégia de API bem-sucedida requer uma mudança de mentalidade do pensamento do produto para o pensamento da plataforma. Isso significa construir produtos de forma modular e aberta que permite que sua funcionalidade seja recombinada e que priorize a flexibilidade para os desenvolvedores consumidores. Pense nos sistemas de estantes da IKEA, que os clientes podem comprar, montar e personalizar de diferentes maneiras para atender a uma variedade de necessidades. Bons gerentes de produto de API veem as APIs pelo que elas são: ferramentas para escalar os negócios e desenvolver parcerias valiosas. Reconhecer esse potencial significa implementar as melhores práticas para garantir a adoção.

Encantando os Desenvolvedores

Se há um pilar fundamental de uma estratégia de API sólida, é a experiência do desenvolvedor (DX). Para integrações de API, os gerentes de produto dos “clientes” precisam encantar os desenvolvedores consumidores. Esses são os usuários que finalmente chamam/integram com uma API, os parceiros em potencial que podem ajudar a concretizar uma visão de produto para plataforma. Rotular sua experiência como “DX” em vez de “UX” reconhece que eles não são usuários finais típicos – eles são significativamente mais aptos tecnicamente. Para ter empatia com eles, é essencial entender suas necessidades e expectativas específicas.

Melhores Práticas

A seguir, embora não represente uma lista exaustiva, são práticas essenciais para a criação de APIs de primeira linha que garantem experiências de integração previsíveis, consistentes e sem atritos para desenvolvedores consumidores. Os gerentes de produto devem abordar o design de APIs de maneira escalável, definindo uma estrutura de práticas recomendadas e publicando-a como um documento que as equipes podem consultar ao criar novas APIs.

Convenções de nomenclatura e endpoints consistentes

Estabelecer convenções de nomenclatura consistentes para endpoints de API que identifiquem claramente a natureza e a finalidade da API elimina a ambiguidade e contribui para um DX positivo e previsível. É melhor escolher uma URL base comum para todas as APIs e uma estrutura para a URL final que evite jargões e abreviações. As APIs nórdicas oferecem uma lista útil de dicas para nomear endpoints.

Estruturas detalhadas de resposta a falhas e sucessos

Os desenvolvedores querem e esperam objetos de dados familiares e códigos de status para respostas de sucesso e falha. Isso significa um código de status 2xx para cenários de sucesso, um código 4xx para falhas do lado do cliente e um código 5xx para erros do lado do servidor. No entanto, a especificidade é fundamental. Uma chamada para uma API de “enviar email” que simplesmente retorna uma resposta 4xx sem informações adicionais contribui para uma experiência ruim para o desenvolvedor, porque apenas confirma que o erro estava na solicitação do cliente sem fornecer informações adicionais sobre o que exatamente deu errado.

 { "status": 400, "message": "incorrect request" }

Por outro lado, uma resposta que oferece detalhes específicos em formato legível por humanos e na forma de um código de erro exclusivo pode ajudar os desenvolvedores a decidir rapidamente como corrigir o cenário de erro, escrever código para resolver o problema e tentar novamente a chamada da API.

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

Para um DX ideal, as estruturas de resposta e as chaves que comunicam o status devem ser consistentes entre as APIs. Por exemplo, o campo de código de erro acima deve ser invariavelmente referido como “código” em cada API, não “código” em algumas APIs e “errorCode” em outras.

Limites de taxa configuráveis

Os limites de taxa controlam a acessibilidade de uma API, determinando quantas vezes um usuário pode chamá-la em uma única unidade de tempo. Limites de taxa muito altos podem inundar os sistemas com um número incontrolável de solicitações que degradam o desempenho, enquanto limites de taxa excessivamente baixos podem fazer com que transações pendentes sejam enfileiradas nos sistemas dos usuários. Ambos contribuem para um DX ruim. Ao projetar APIs, é melhor permitir limites de taxa que podem ser ajustados com base em casos e circunstâncias de negócios específicos. Clientes de alto volume, por exemplo, podem ter uma necessidade genuína de chamar APIs com mais frequência.

Para melhor determinar os limites de taxa apropriados, é útil primeiro agrupar as APIs em categorias significativas de acordo com a frequência e o volume com que são chamadas. Por exemplo, APIs que configuram dados primários do cliente (criação de perfil/conta) são chamadas com menos frequência e podem lidar com limites de taxa mais baixos, enquanto APIs de transação (“criar pedido”, “enviar email”) são chamadas com mais frequência, exigindo limites de taxa mais altos. Estabelecer categorias, ou camadas, para diferentes casos de uso torna APIs mais confiáveis ​​e escaláveis. Para obter um exemplo de limites de taxa claramente definidos, consulte a documentação da API do Slack.

Documentação abrangente

A documentação serve como o manual do usuário para uma API. Ele articula claramente aos desenvolvedores o que uma API faz, como usá-la e o que esperar dela. Uma boa documentação é escrita em linguagem clara e acessível, é detalhada e interativa e oferece muitas demonstrações e trechos de código para simplificar a integração. Dessa forma, facilita a integração fácil e um Time to First Hello World (TTFHW) rápido, uma métrica importante que representa a rapidez com que um desenvolvedor pode chamar com sucesso sua primeira API.

A documentação deve identificar claramente quais campos na solicitação de API são obrigatórios e quais são opcionais, bem como o tamanho mínimo e máximo e o tipo de dados desses campos. Essencialmente, deve incluir tudo o que é necessário para definir expectativas e remover obstáculos para desenvolvedores consumidores. Desenvolvedores que criam esquemas de banco de dados em seus sistemas, por exemplo, não devem ter que ajustar posteriormente o comprimento das colunas nas tabelas porque a documentação não especifica os parâmetros.

A documentação da API pode aumentar a adoção não apenas servindo como uma referência confiável para desenvolvedores consumidores, mas também atuando como uma ferramenta de marketing para a própria API. Muitas vezes, a primeira pessoa a encontrar a documentação da API é uma parte interessada voltada para os negócios, que a navega durante as fases iniciais da avaliação do produto. Portanto, deve incluir não apenas detalhes sobre os elementos técnicos da API, mas também articular claramente os casos de uso de negócios que a API possibilita.

Existem várias ferramentas no mercado que podem ajudar a gerar uma documentação abrangente de API. A revisão de exemplos de documentação de alta qualidade, como a do Stripe, também é útil.

Juntando tudo

As integrações representam um vasto domínio com muitos componentes, mas entender os princípios fundamentais de uma boa API é fundamental para desenvolver uma estratégia sólida. As APIs são muito, muito mais do que meros conectores de sistema. Eles são os blocos de construção de redes digitais expansivas e as chaves para abrir novos fluxos de receita e liberar valor inexplorado. Por isso, uma estratégia de API bem-sucedida não se resume apenas à criação de produtos; trata-se de construir potencial. Um gerente de produto de API deve adotar uma mentalidade de plataforma e priorizar os fatores que facilitarão a adoção para os parceiros em potencial que podem usar sua API, integrá-la e executá-la.