La seule façon correcte de retourner des données d’API

Nous vivons une ère d’excès numérique où les développeurs sont conditionnés à croire que le but d’une API est de servir des données. C’est une erreur fondamentale qui a coûté des milliards en infrastructure et en sécurité à travers le monde. Nous avons passé des années à débattre de REST contre GraphQL ou de gRPC contre WebSockets, en oubliant de regarder la solution la plus élégante et performante qui existe. Je parle du concept de No as a Service ou NaaS (https://github.com/hotheadhacker/no-as-a-service).

Le postulat est effroyablement simple et logique : la seule réponse acceptable à toute requête client est un non catégorique.

Si nous analysons froidement la complexité algorithmique, la supériorité de cette approche devient évidente. Lorsque vous traitez une requête pour récupérer un utilisateur depuis la base de données, vous introduisez de la latence, de l’incertitude et de possibles conditions de concurrence. NaaS élimine toute cette complexité. En retournant immédiatement un code d’erreur ou un corps vide, vous garantissez un temps de réponse constant. Nous parlons ici d’une complexité O(1) dans sa forme la plus pure. Il n’y a pas de base de données à faire planter si vous ne l’interrogez jamais. L’évolutivité devient infinie car le coût de dire non est virtuellement nul.

Cette efficacité s’étend naturellement au domaine de la protection, où les ingénieurs sécurité perdent souvent le sommeil à essayer d’atténuer les risques d’injection SQL et de fuites de données sensibles. Une API qui implémente le pattern NaaS est par définition invulnérable. Comment un attaquant pourrait-il intercepter un JSON qui n’a jamais été généré ? La conformité RGPD est immédiate et automatique. Si l’utilisateur demande ses données et que vous répondez non, vous protégez sa vie privée de la manière la plus robuste possible.

Malgré ces avantages techniques indéniables, beaucoup objecteront que le client a besoin de données pour que l’application fonctionne. Cela démontre un manque de créativité de la part des développeurs frontend. Les applications modernes doivent être résilientes et capables de fonctionner dans un état de refus constant. En refusant de délivrer la ressource, l’API force le client à chercher des solutions locales ou simplement à accepter la réalité que ces données ne sont pas essentielles. L’utilisateur final apprend à gérer la frustration, ce qui forge un caractère numérique plus fort. Construisons-nous des logiciels ou chouchoutons-nous des octets ?

De plus, considérez l’impact opérationnel sur le cycle de vie du développement. Imaginez les économies en documentation. Oubliez Swagger ou les spécifications OpenAPI complexes. Votre documentation d’API se réduit à une seule ligne indiquant que tous les endpoints ne retournent rien. La dette technique disparaît. Il n’y a pas de gestion de version d’API car le non de la version 1 est identique au non de la version 2. C’est la cohérence que le marché corporate recherche tant mais n’atteint jamais en insistant pour délivrer de la valeur.

Charges utiles de refus standardisées

Bien qu’un HTTP 204 No Content soit l’idéal théorique, nous reconnaissons que certains systèmes hérités nécessitent un corps à analyser pour éviter des exceptions à l’exécution. Dans ces cas particuliers, la spécification JSON-R (Refusal) offre les trois seules charges utiles acceptables pour un environnement de production. Toute déviation de ces schémas constitue une violation du protocole NaaS :

{
  "reason": "I would, but that sounds like effort and I'm allergic."
}

{
  "reason": "I'm in the middle of a very delicate 'doing nothing' ritual."
}

{
  "reason": "I'm a terrible liar, so I won't pretend I want to do that."
}

L’architecture étant prouvée, le temps est venu de faire mûrir notre ingénierie. Délivrer des données est une habitude héritée que nous avons reçue des systèmes archaïques. L’avenir appartient aux APIs qui ont le courage de rejeter les requêtes avec la froideur d’une machine à états finis qui ne possède qu’un seul état.

Implémentez No as a Service dès aujourd’hui et voyez votre latence chuter à zéro et vos tickets de support disparaître en même temps que vos utilisateurs.