Vérifiez si une méthode HTTP est sûre ou idempotente

Classez une méthode HTTP standard selon les propriétés de sûreté et d’idempotence définies par la sémantique HTTP. Saisissez une méthode comme GET, POST, PUT, PATCH ou DELETE pour obtenir son nom normalisé, deux résultats booléens distincts et une classification synthétique. Le vérificateur reconnaît les neuf méthodes définies dans les principales spécifications relatives à la sémantique HTTP et à PATCH, ignore les espaces périphériques et la casse, puis rejette les noms inconnus au lieu de supposer les propriétés d’une méthode d’extension.

Distinguez la sûreté de l’idempotence

La sûreté et l’idempotence correspondent à deux garanties différentes. Une méthode sûre sert à récupérer des informations ou à communiquer des options, et non à demander une modification d’état au serveur d’origine. L’idempotence couvre un champ plus large : plusieurs requêtes identiques ont le même effet recherché sur le serveur qu’une seule requête. PUT et DELETE sont idempotentes sans être sûres, car remplacer plusieurs fois une représentation par la même représentation ou demander plusieurs fois la suppression de la même ressource n’ajoute pas un nouvel effet recherché à chaque exécution. GET, HEAD, OPTIONS et TRACE sont sûres. La sémantique HTTP précise également que toute méthode sûre est idempotente ; ces méthodes reçoivent donc la classification combinée `safe_and_idempotent`. La réponse fournit `safe` et `idempotent` séparément afin que votre code de règles n’ait pas à déduire une propriété d’une étiquette. Elle renvoie aussi le champ `classification`, pratique pour l’affichage, la journalisation ou une condition simple. Ces propriétés décrivent la sémantique normalisée des requêtes et ne garantissent pas qu’une implémentation particulière soit exempte de défauts ou d’effets secondaires accessoires.

Interprétez correctement les nouvelles tentatives

POST et PATCH sont classées comme ni sûres ni idempotentes dans leur définition générale. Une API particulière peut concevoir une opération POST ou PATCH répétable, éventuellement grâce à une clé d’idempotence ou à une requête conditionnelle, mais ce contrat applicatif ne modifie pas la propriété normalisée par défaut de la méthode. Utilisez ce résultat comme base protocolaire, puis appliquez les garanties supplémentaires que l’API appelée documente explicitement.

Validez le nom avant d’appliquer une règle

Deviner les propriétés d’une méthode d’extension à partir de son nom pourrait autoriser une répétition dangereuse ou bloquer une opération valide. Si votre système emploie une telle méthode, consultez la spécification qui l’enregistre ou la définit et traitez-la au moyen d’une règle explicite. L’algorithme n’effectue aucune requête réseau et n’observe aucun serveur, aucune route, aucun cache, aucun proxy ni aucun corps réel. Le vérificateur accepte les noms standard CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT et TRACE. L’entrée est débarrassée de ses espaces périphériques puis convertie en majuscules ; des valeurs comme ` get ` et `patch` sont donc normalisées sans changer de sens. Toute autre valeur produit une erreur `invalid_input`. Cette rigueur est importante, car les jetons de méthode HTTP sont extensibles : WebDAV et d’autres protocoles définissent des méthodes supplémentaires, tandis que des API privées peuvent introduire leurs propres jetons. Déterministe, il convient aux linters, aux contrôles de documentation d’API, à la configuration des mécanismes de répétition et aux outils pédagogiques dans le navigateur. Le navigateur et le gestionnaire API partagent la même logique ; une requête API applique le tarif de base publié de $0.002.