This...is Programming Like a Fighter Pilot.

A single unhandled exception destroyed a $500 million rocket in seconds.

The F-35 wasn't going to make the same mistake.

By carefully slicing C++, engineers created one of the strictest coding standards ever written. pic.twitter.com/AO9VhrLFqs

— LaurieWired (@lauriewired) December 3, 2025

Rust is a programming language solution looking for a great problem to solve. I was thinking... why not rewrite the F-35 fighter's eight million lines of C++ in Rust? That would be perfect, and much better/safer.

— kgk (@kgk) October 13, 2025

• Pas d'exceptions : la gestion des exceptions C++ est entièrement interdite afin de garantir une exécution déterministe.
• Pas d’allocation dynamique de mémoire : l'utilisation de malloc, free et new/delete est généralement interdite après l'initialisation afin d'éviter les fuites de mémoire et la fragmentation.
• Pas de récursivité : la récursivité est interdite afin d'éviter les débordements de pile et de rendre le temps d'exécution prévisible.
• Complexité limitée : chaque fonction doit être suffisamment simple (complexité cyclomatique ≤ 20) pour que tous les chemins de décision puissent être testés de manière approfondie.

• Créer et supprimer les mêmes enregistrements des centaines de fois par minute, sans raison valable
  
• Interroger un point de terminaison /index volumineux sans délai entre les requêtes, indéfiniment
  
• Importer ou exporter une tonne de données sans reculer en cas d'erreurs

• Les API sont difficiles à créer car elles sont rigides, mais elles doivent être faciles à adopter.
  
  
• La principale responsabilité des responsables de la maintenance des API est de NE PAS PERTURBER L'ESPACE UTILISATEUR. N'apportez jamais de modifications radicales aux API publiques.
  
  
• La gestion des versions de votre API vous permet d'apporter des modifications, mais impose des obstacles importants en termes de mise en œuvre et d'adoption.
  
  
• Si votre produit a suffisamment de valeur, la qualité de votre API n'a pas vraiment d'importance, les gens l'utiliseront de toute façon.
  
  
• Si votre produit est suffisamment mal conçu, peu importe le soin que vous apportez à la conception de votre API, elle sera probablement mauvaise.
  
  
• Votre API doit prendre en charge des clés API simples pour l'authentification, car bon nombre de vos utilisateurs ne seront pas des ingénieurs professionnels.
  
  
• Les requêtes qui entraînent une action (en particulier les actions à haut risque comme les paiements) doivent inclure une sorte de clé d'idempotence afin de sécuriser les nouvelles tentatives.
  
  
• Votre API sera toujours une source d'incidents. Assurez-vous de mettre en place des limites de débit et des coupe-circuits.
  
  
• Utilisez la pagination par curseur pour les ensembles de données qui pourraient finir par être très volumineux.
  
  
• Rendez les champs coûteux facultatifs et désactivés par défaut, mais (à mon avis) GraphQL est excessif.
  
  
• Les API internes sont différentes à certains égards (car vos consommateurs sont très différents).

• REST est CRUD (c'est souvent le cas, mais pas toujours)
• Une ressource est une entité (souvent une entité persistante).
• Une API RESTful ne doit pas utiliser de verbes.

{
  "orderId": 123,
  "_links": {
    "self": { "href": "/orders/123" },
    "cancel": { "href": "/orders/123/cancel", "method": "POST" }
  }
}

1. Une API REST ne doit pas dépendre d'un protocole de communication unique, même si son mappage réussi à un protocole donné peut dépendre de la disponibilité des métadonnées, du choix des méthodes, etc. En général, tout élément de protocole qui utilise un URI pour l'identification doit permettre l'utilisation de n'importe quel schéma URI à des fins d'identification. [Un échec à cet égard implique que l'identification n'est pas séparée de l'interaction.]
   
   
2. Une API REST ne doit pas contenir de modifications des protocoles de communication, à l'exception du remplissage ou de la correction des détails des bits sous-spécifiés des protocoles standard, tels que la méthode PATCH ou le champ d'en-tête Link de HTTP. Les solutions de contournement pour les implémentations défectueuses (telles que les navigateurs assez stupides pour croire que HTML définit l'ensemble des méthodes HTTP) doivent être définies séparément, ou au moins dans des annexes, en espérant que la solution de contournement finira par devenir obsolète. [Tout manquement à cette règle implique que les interfaces de ressources sont spécifiques à un objet et non génériques.]
   
   
3. Une API REST doit consacrer la quasi-totalité de ses efforts descriptifs à la définition des types de médias utilisés pour représenter les ressources et piloter l'état de l'application, ou à la définition de noms de relations étendus et/ou de balises hypertextes pour les types de médias standard existants. Tout effort consacré à la description des méthodes à utiliser sur les URI d'intérêt doit être entièrement défini dans le cadre des règles de traitement d'un type de média (et, dans la plupart des cas, déjà défini par les types de médias existants). [Tout manquement à cette règle implique que l'interaction est pilotée par des informations hors bande plutôt que par l'hypertexte.]
   
   
4. Une API REST ne doit pas définir de noms ou de hiérarchies de ressources fixes (couplage évident entre le client et le serveur). Les serveurs doivent avoir la liberté de contrôler leur propre espace de noms. Au lieu de cela, permettez aux serveurs d'indiquer aux clients comment construire des URI appropriés, comme cela se fait dans les formulaires HTML et les modèles d'URI, en définissant ces instructions dans les types de médias et les relations de lien. [Un échec à cet égard implique que les clients supposent une structure de ressources en raison d'informations hors bande, telles qu'une norme spécifique à un domaine, qui est l'équivalent orienté données du couplage fonctionnel du RPC].
   
   
5. Une API REST ne doit jamais comporter de ressources « typées » qui sont significatives pour le client. Les auteurs de spécifications peuvent utiliser des types de ressources pour décrire l'implémentation du serveur derrière l'interface, mais ces types doivent être sans importance et invisibles pour le client. Les seuls types qui sont significatifs pour un client sont le type de média de la représentation actuelle et les noms de relations standardisés. [idem]
   
   
6. Une API REST doit être accessible sans connaissance préalable autre que l'URI initiale (signet) et un ensemble de types de médias standardisés adaptés au public visé (c'est-à-dire compréhensibles par tout client susceptible d'utiliser l'API). À partir de là, toutes les transitions d'état de l'application doivent être déterminées par le choix du client parmi les options fournies par le serveur qui sont présentes dans les représentations reçues ou implicites dans la manipulation de ces représentations par l'utilisateur. Les transitions peuvent être déterminées (ou limitées) par la connaissance qu'a le client des types de médias et des mécanismes de communication des ressources, qui peuvent tous deux être améliorés à la volée (par exemple, code à la demande). [Un échec à ce niveau implique que ce sont des informations hors bande qui déterminent l'interaction plutôt que l'hypertexte.]

{
  "name": "John Doe",
  "status": "inactive",
  "_links": {
    "self": { "href": "/users/123" },
    "activate": { "href": "/users/123/activate", "method": "POST" }
  }
}

{
  "_links": {
    "user": { "href": "/users/123" },
    "orders": { "href": "/users/123/orders" }
  }
}