14 pièges de la stratégie API à éviter

De bonnes API sont une partie essentielle d'un bon code. Ce sont les limites que les développeurs tracent lorsque nous divisons des projets, créons des bibliothèques et partageons notre travail. Comme Robert Frost l'a dit il y a longtemps, "les bonnes clôtures font les bons voisins". S'il était vivant aujourd'hui, il écrirait ce poème sur les API.

De plus en plus, de bonnes API sont également à la base d'une bonne entreprise. Ils ne sont pas seulement une passerelle vers des données et des informations décisionnelles, mais un produit conçu pour les monétiser. Les API suivent leurs utilisateurs et trouvent un moyen équitable de les facturer.

Hélas, créer ces API n'est pas aussi simple que d'ouvrir un port TCP/IP et d'attendre que l'argent le fasse rouler. Lâchée de cette façon, une API recevra les demandes de chaque appareil sur Internet, et tout le chaos, à la fois malveillant et innocent, commencera à frapper à la porte de l'entreprise. Le défi consiste à rendre une API facile à utiliser et accueillante pour les bons développeurs tout en étant impénétrable pour les mauvais.

Voici 14 problèmes d'API courants qui peuvent faire échouer votre stratégie d'API.

Oublier le prix de l'exfiltration.

De nombreux fournisseurs de cloud facturent une longue liste d'événements et certains sont faciles à oublier. Le coût d'une machine par heure est évident, mais beaucoup oublient que la facture peut inclure "l'exfiltration de données". Hélas, le travail principal d'une API est d'exfiltrer les données aux utilisateurs. Assurez-vous de tenir compte de ce coût lors de la tarification de votre API, ainsi que lors de l'esquisse de l'architecture.

Ignorer la "taxe sur le format de données"

Certains formats de données tels que XML ne sont pas aussi efficaces que d'autres, ce qui peut affecter la taille des paquets de données que votre API renverra. Une de mes amies aime toujours se vanter d'avoir réduit les factures de données de son entreprise de plus de 40 % simplement en se débarrassant des balises supplémentaires et de la saleté dans le format des données. Gardez le format de données aussi léger que possible et gardez les données concentrées uniquement sur les bits nécessaires pour que vos factures de bande passante restent gérables. La plupart du temps, ceux-ci ne posent aucun problème, même s'ils ne sont pas utilisés. Mais parfois, ils laissent des failles de sécurité qui passent inaperçues.

Le programmeur qui a ajouté la possibilité d'exécuter du code arbitraire à la bibliothèque Log4J n'avait pas prévu de créer l'un des pires bogues de sécurité de l'histoire d'Internet, mais lorsque les gens ont oublié le pouvoir de cette fonctionnalité rarement utilisée, il est devenu juste cela. Dans des cas comme celui-ci, il est utile de ne pas être trop créatif ou intelligent. S'en tenir au strict minimum n'est pas toujours la meilleure façon de créer un excellent produit, mais cela peut être un bon moyen de créer une API sécurisée.

Oublier de pré-filtrer

La plupart des API ne font pas beaucoup de travail elles-mêmes . Ils prennent l'entrée et la transmettent à un autre code. L'un des meilleurs services qu'une API peut offrir est le pré-filtrage pour s'assurer que les entrées sont conformes aux attentes. Bon nombre des pires bogues de sécurité provenaient d'attaques qui abusent de la bonne volonté naïve de certaines API pour déborder un tampon ou générer une attaque par injection SQL.

Lésiner sur les tests

De nombreux développeurs ont quelques URL de test de base. Si le bon paquet revient de l'API, ils supposent que tout se passe bien. En réalité, les résultats des tests sont souvent mis en cache et les URL de test simples peuvent n'exercer que la première couche. Une bonne suite de tests s'assurera de toucher chaque partie d'une API, en particulier sa connexion avec la base de données et les API ou services secondaires. La réponse est mélangée directement avec un autre contenu dans un navigateur. Cela peut être un défi pour certains utilisateurs d'API qui se précipitent pour utiliser l'API. Parfois, la réponse consiste à ajouter la balise Access-Control-Allow-Origin aux en-têtes. Parfois, il est préférable de créer un proxy complet dans la pile.

Choisir la mauvaise autorisation

Déterminer le bon montant d'autorisation pour votre API est un peu un art. Certaines données ne sont pas trop sensibles. Le seul travail de l'API est de suivre les utilisateurs pour déterminer les factures. Pour ces cas plus simples, une clé aléatoire invariable peut suffire. D'autres API, cependant, protègent les informations personnelles qui peuvent être incroyablement sensibles. Dans ces cas, des protocoles plus sécurisés tels que OAuth 2.0, OpenID ou JWT sont de meilleurs choix. Il existe déjà de bonnes bibliothèques pour les deux extrémités des protocoles, donc la mise à niveau de la sécurité ne nécessite pas d'écrire beaucoup de nouveau code. , les programmeurs ont tendance à faire une sieste. Les fichiers journaux des API, cependant, peuvent aider à signaler un danger avant qu'il ne se produise. Des paramètres particuliers causent-ils plus de problèmes au logiciel ? La charge augmente-t-elle certains jours, à certaines heures ou lorsqu'un client se présente ? Passer quelques minutes à parcourir les fichiers journaux pour détecter les mauvais temps de réponse peut mettre en évidence les endroits où votre matériel est sous-alimenté ou où votre logiciel a des problèmes. Résoudre ces problèmes maintenant empêchera un véritable effondrement plus tard lorsqu'une tempête parfaite fournira plusieurs datagrammes désagréables à la fois. Lorsque la mise en cache fonctionne bien, tout le monde obtient une réponse suffisamment récente pour ses besoins. Mais lorsque la mise en cache est trop agressive, les utilisateurs se retrouvent avec des réponses obsolètes et aucun moyen de savoir quand elles ont été générées. L'utilisation de peu ou pas de mise en cache résoudra ce problème, mais au prix de plus de calculs et de complexité. Trouver le bon équilibre peut être un défi.

Rouler soi-même ou utiliser un framework

Les API sont désormais suffisamment courantes pour que les programmeurs aient construit de bons frameworks tels que Swagger, OpenAPI ou l'une des versions commerciales des sociétés de cloud. . Vous écrivez juste quelques lignes pour spécifier les paramètres et le framework fait le gros du travail. Ces cadres ont de bons filtres pour arrêter les abus et offrent des compteurs modernes pour suivre l'utilisation. Créer votre propre version est de plus en plus stupide.

Ignorer un niveau gratuit

Si votre API est destinée à un public général de développeurs d'un large éventail d'entreprises, alors un niveau gratuit peut être le moyen le plus simple d'attirer de nouveaux utilisateurs. Si les codeurs doivent demander au patron une ligne budgétaire et une autorisation, il leur est plus difficile d'expérimenter et de montrer à tout le monde ce que votre API peut fournir. Le danger, cependant, est que le niveau gratuit sera si généreux que ces développeurs continueront à utiliser l'API sans devenir des clients payants. Trouver la bonne quantité est difficile et spécifique à l'API. Certaines API sont faciles à mettre en cache car les données sous-jacentes ne changent pas et cela signifie que les utilisateurs gratuits peuvent être en mesure d'étendre l'accès. Soyez avare de données faciles à mettre en cache pendant de longues périodes. Mais envisagez d'être plus généreux si la sortie principale devient rapidement obsolète ou risque de ne jamais être mise en cache. Définissez un nombre trop bas et vous manquez vos objectifs de revenus. Réglez-le trop haut et les gens s'en vont. Toutes les techniques standard de marketing et de tarification sont équitables. Certaines entreprises réservent des niveaux premium pour capter les revenus des gros utilisateurs. D'autres fixent un prix public élevé et proposent ensuite de généreuses offres privées. Il n'y a pas de réponse unique au problème et les gens des écoles de commerce écrivent des doctorats sur ces défis marketing. idéal pour plusieurs. Ils offrent un prix simple qui est presque directement proportionnel à l'utilisation, ce qui simplifie considérablement la conception d'un modèle commercial fonctionnel. Si la société de cloud facture X $ pour chaque invocation de fonction et que chaque appel d'API se transforme en une invocation de fonction, eh bien, il n'est pas difficile de voir que vous devrez facturer au moins X $ pour chaque API juste pour atteindre le seuil de rentabilité de l'infrastructure. Toutes les API ont d'autres coûts et certains peuvent être substantiels, mais à tout le moins, les modèles sans serveur permettent aux compteurs de haricots de calculer plus facilement certains des coûts variables d'exécution d'une API.

Ne pas s'amuser avec les messages d'erreur

Qui créé le message 404 personnalisé ? Il existe plusieurs opportunités dans chaque API pour injecter de l'humour. Les requêtes vides ou mal formatées sont évidentes, mais votre API particulière peut avoir de bons endroits pour cacher les œufs de Pâques. Les équipes d'ingénieurs qui conçoivent Siri et Alexa devaient avoir une réponse pour "Ouvrez les portes de la baie de pod". Quelle sera la vôtre ?