Stability AI traz nova clareza e potência para geração de áudio AI com Stable Audio 2.0
3 de abril de 2024Usando um portal de desenvolvedor interno para visibilidade de FinOps
3 de abril de 2024Mais da metade (71%) do tráfego da web em 2023 veio de chamadas de API. Como base da modernização digital, as APIs e os dados que elas expõem desempenham um papel crucial na viabilização das experiências digitais contínuas que desfrutamos todos os dias, desde aplicativos móveis até serviços em nuvem. No entanto, a rápida proliferação de APIs introduziu desafios significativos, especialmente quando se trata de design de APIs e gerenciamento de longo prazo.
Essencialmente, as APIs atuam como contratos entre componentes de software. Eles definem como um cliente pode solicitar dados, quais dados estão disponíveis e como estão estruturados. No entanto, uma vez que uma API é colocada em produção e consumida, a capacidade de modificar seu design e especificações é significativamente limitada.
Mas espere, as APIs não foram projetadas para serem robustas e adaptáveis? Bem, as APIs podem ser aditivas – permitindo a adição de novas funcionalidades. Porém, alterar ou remover funcionalidades pode causar um efeito cascata de problemas. Depois de publicadas, as APIs não são consumidas apenas pela equipe de desenvolvimento original. Eles são frequentemente usados por clientes externos, equipes de desenvolvimento internas e até mesmo por outros aplicativos. Isso significa que quaisquer alterações no design ou nas especificações da API podem ter efeitos de longo alcance, impactando não apenas o aplicativo original, mas todos os outros aplicativos ou serviços que dependem da API. É aí que reside um dos principais desafios ao trabalhar com APIs: a capacidade limitada de alterar ou modificar uma API depois de publicada.
Esse enigma dá origem ao que poderia ser chamado de “fantasmas do passado de desenvolvimento de APIs”. Estas são decisões de design de API mal tomadas que, uma vez em produção, podem causar dor e sofrimento para empresas, clientes e equipes de desenvolvimento durante anos.
Aqui estão três maneiras pelas quais decisões inadequadas de design de API podem ter implicações duradouras:
- Escalabilidade limitada: à medida que as empresas se expandem e exigem mais recursos, APIs mal projetadas podem prejudicar sua capacidade de dimensionar as operações de maneira eficaz. Por exemplo, se um desenvolvedor não considerar adequadamente a necessidade de escalabilidade no design de uma API, a API terá dificuldades para lidar com o aumento de cargas de uma crescente população de usuários. Isso pode levar a gargalos de desempenho, tempos de resposta mais lentos e tempo de inatividade durante períodos de pico de uso. Além disso, é essencial considerar a compatibilidade com versões anteriores. Digamos que você tenha uma API que busca dados para um cliente. Se você estiver introduzindo o cache em uma versão mais recente da API, isso melhorará o desempenho, mas os clientes mais antigos ainda poderão usar versões desatualizadas, prejudicando o desempenho geral do sistema.
- Aumento de custos: Decisões inadequadas de design de API também podem levar ao aumento dos custos operacionais. Por exemplo, manter e gerenciar APIs obsoletas ou desatualizadas pode consumir tempo e recursos significativos que poderiam ter sido melhor utilizados em outro lugar. Se uma API não for projetada para escalar, ela também poderá exigir recursos substanciais para ser corrigida no futuro, à medida que o negócio crescer, gerando custos adicionais. Cumulativamente, essas ineficiências podem impactar negativamente os resultados financeiros de uma organização.
- Riscos de segurança: embora a segurança seja um aspecto crítico do design da API, ela costuma ser esquecida. Os desenvolvedores normalmente se concentram em tornar a API o mais útil possível, mas, ao fazer isso, podem criar inadvertidamente vulnerabilidades que os invasores podem explorar. Por exemplo, deixar de especificar o intervalo para uma variável de string pode deixar uma API vulnerável a ataques de buffer overflow, onde um invasor tenta sobrecarregar o sistema enviando mais dados do que a API pode suportar. Se as vulnerabilidades de segurança da API forem exploradas, isso poderá causar danos financeiros e de reputação significativos aos negócios.
A questão do design deficiente das APIs é ainda agravada pelo fato de que não existem padrões rígidos sobre como as APIs devem ser projetadas. Isso deixa a cargo dos desenvolvedores individuais determinar a melhor maneira de implementar e desenvolver APIs, o que significa que decisões de design inadequadas podem facilmente escapar. Em um estudo recente, descobriu-se que uma organização média possui 613 endpoints de API. Isto significa que para cada organização existem potencialmente centenas de APIs, cada uma com o seu próprio conjunto de desafios de design únicos e potenciais riscos de segurança.
Depois que uma API está em produção, torna-se um processo caro e demorado corrigir problemas de design. Mesmo quando os desenvolvedores percebem seus erros, muitas vezes não conseguem corrigi-los, a menos que criem uma nova versão da API. Embora a criação de uma nova versão da API possa parecer uma solução simples, ela apresenta desafios. Além do mais, quando uma nova versão é lançada, a versão antiga não desaparece imediatamente. Na verdade, APIs obsoletas muitas vezes voltam dos mortos à medida que os clientes continuam a usá-las ou as equipes não conseguem descontinua-las totalmente. Isto leva a problemas de gestão contínuos e pode introduzir potenciais vulnerabilidades de segurança. Além disso, APIs obsoletas que continuam a ser usadas podem se tornar um risco de segurança significativo. Essas APIs podem não ser mantidas ou atualizadas com os patches de segurança mais recentes, o que as torna um alvo fácil para os cibercriminosos.
Para navegar com sucesso por esses desafios, há cinco etapas que os desenvolvedores devem seguir:
- Priorize o design da API desde o início: em vez de apressar a implementação, concentre-se em projetar a API corretamente. Considere escalabilidade, segurança e manutenção de longo prazo ao projetar uma API. Isso inclui considerar o crescimento potencial do negócio, os tipos de dados que a API irá manipular e como a API será usada por outros aplicativos ou serviços. Uma API bem projetada pode minimizar custos futuros, reduzir riscos de segurança e garantir que a API possa ajudar a empresa a dimensionar suas operações digitais no futuro.
- Adote as melhores práticas de design de API: embora possa não haver padrões rígidos para o design de APIs, existem práticas recomendadas que devem ser seguidas. Isso inclui o uso de princípios RESTful para APIs da web, o uso de convenções de nomenclatura consistentes e o uso de linguagens de descrição de API como OpenAPI ou RAML. Da mesma forma, aderir à especificação OpenAPI pode fornecer uma estrutura para planejar, projetar, construir, testar e documentar APIs. A implementação dessas práticas recomendadas pode garantir que uma API seja fácil de usar e entender, o que pode reduzir a probabilidade de erros de design e melhorar a qualidade geral da API.
- Entenda e prepare-se para riscos de segurança: A segurança nunca deve ser deixada de lado quando se trata de design de API. Garanta que as APIs sejam projetadas para lidar com uma série de possíveis ameaças à segurança, desde ataques de buffer overflow até injeção de SQL. Isso inclui validar e higienizar dados de entrada, implementar limitação de taxa para evitar ataques de negação de serviço e usar protocolos seguros como HTTPS. Uma ferramenta de segurança de API também deve ser implementada para monitorar e minimizar o risco de um incidente de segurança, bem como proteger as APIs contra uma série de ataques automatizados e de dia zero que mesmo o design adequado da API não pode contabilizar.
- Audite e atualize APIs regularmente: Revisões e atualizações regulares podem ajudar a identificar e corrigir problemas de design antes que se tornem problemas graves. Isso inclui testar regularmente a API em busca de vulnerabilidades de desempenho e segurança, bem como coletar feedback dos usuários para identificar possíveis áreas de melhoria. Se um problema de design for identificado, não hesite em criar uma nova versão da API, mas certifique-se de seguir uma estratégia adequada de controle de versão da API. Embora isso possa exigir trabalho adicional, pode ajudar a garantir que a API continue a atender às necessidades da empresa e de seus usuários.
- Planeje a evolução da API: APIs não são imutáveis. Eles precisarão evoluir ao longo do tempo para se alinharem às mudanças nos objetivos de negócios e nas necessidades dos clientes. Portanto, planeje a mudança desde o início. Isso inclui projetar APIs de uma forma que permita a adição de novos recursos sem interromper a funcionalidade existente e planejar a descontinuação de versões antigas. Quando uma nova versão de uma API for lançada, certifique-se de que essa alteração seja comunicada a todos os usuários, forneça caminhos de migração claros e continue a oferecer suporte à versão antiga por um período razoável. Também é importante ter uma política de descontinuação clara e comunicar quaisquer alterações de API aos usuários com bastante antecedência.
Gerenciar e proteger APIs é uma responsabilidade contínua e constante. Com o surgimento de novas tecnologias, padrões e melhores práticas, os desenvolvedores devem permanecer vigilantes. Envolve reservar um tempo para se manter atualizado sobre essas mudanças e refinar continuamente suas habilidades.
Enfrentar os fantasmas do passado de desenvolvimento de APIs requer uma mudança de mentalidade. Embora a rápida proliferação de APIs tenha trazido desafios significativos, especialmente quando se trata de design e gerenciamento de longo prazo, esses desafios podem ser superados com sucesso com um planejamento cuidadoso, conhecimento dos riscos de segurança e uma abordagem inovadora ao design de APIs. Ao priorizar essas áreas, os desenvolvedores podem ajudar a garantir que suas APIs sejam escalonáveis, seguras e capazes de suportar o crescimento e a evolução futuros dos negócios.
A postagem O design da API é muito ruim – veja como consertar apareceu pela primeira vez em The New Stack.