02. Méthodes et sémantique des opérations

Comprendre le mécanisme

GET demande une représentation ; il n’est pas conçu pour déclencher une mutation métier. POST soumet un traitement selon le contrat de la ressource. PUT vise un remplacement dans le cadre défini et DELETE une suppression de l’association à la ressource ciblée. La signification d’une méthode n’implique pas que toute réponse soit identique ni que chaque opération soit autorisée. La sécurité sémantique d’une méthode porte sur l’effet demandé ; un journal technique peut évoluer lors d’une lecture.

Raisonner et vérifier

Définissez une table des opérations avant les routes. Un crawler, un préchargement ou un lien partagé peut provoquer un GET sans intention de mutation de l’utilisateur. Restreindre les méthodes au routeur évite certains déclenchements accidentels, mais ne remplace ni l’identité ni l’autorisation sur l’objet. Testez aussi HEAD et OPTIONS selon votre infrastructure, plutôt que supposer que leur comportement est identique à toutes les autres méthodes.

Lecture sûre

GET demande une lecture selon sa sémantique. Un préchargement peut déclencher une lecture sans intention de mutation. Une annulation déclenchée par GET peut être activée par crawler, préchargement ou visite involontaire. Placez les mutations derrière une méthode et un contrat adaptés, avec autorisation et protection CSRF lorsque nécessaire.

Soumission POST

POST peut soumettre une création. Le verbe ne fournit pas une déduplication durable. POST exprime une soumission au traitement de la ressource. Il ne promet pas automatiquement l’unicité d’un effet ; une création sensible doit définir sa stratégie de déduplication et de reprise.

Idempotence PUT

PUT possède une sémantique idempotente. La propriété concerne l’effet intentionnel des répétitions. L’effet intentionnel d’un PUT répété identique est le même que celui d’un seul. Les journaux peuvent compter plusieurs demandes ; cette sémantique ne signifie pas que chaque réponse sera identique.

DELETE répété

DELETE répété peut constater une absence. Effet et représentation de réponse sont distincts. Après suppression, un second DELETE peut constater l’absence et retourner un autre statut. L’état final peut rester identique : distinguez effet métier et représentation du résultat de chaque tentative.

HEAD

HEAD ne transporte pas de contenu de réponse. HEAD décrit la réponse sans son contenu. HEAD permet d’obtenir les métadonnées d’une représentation sans son contenu de réponse. Le traitement peut néanmoins avoir un coût serveur ; ne le considérez pas automatiquement comme gratuit ou non journalisé.

OPTIONS

OPTIONS peut décrire des capacités de communication. Découverte protocolaire et autorisation sont distinctes. Une réponse OPTIONS peut renseigner les capacités ou participer à un preflight. Elle ne doit pas être interprétée comme une permission métier générale pour un utilisateur ou une ressource donnée.

Restriction de route

Le routeur peut restreindre les méthodes. Le contrôle de méthode ne décide pas des droits. Déclarez les méthodes acceptées et testez une autre méthode sur le même chemin. Ce contrôle réduit les appels hors contrat mais ne prouve pas que l’acteur possède le droit d’annuler une réservation.

Effets accessoires

Une méthode sûre peut produire un journal technique. La sûreté concerne l’effet métier demandé. Une méthode sûre peut écrire un journal ou produire des métriques. L’exigence porte sur l’absence de mutation métier demandée implicitement, pas sur l’interdiction de toute activité interne du serveur.

Client libre

Un client direct peut ignorer les boutons affichés. L’interface ne constitue pas la frontière d’accès. Le visiteur n’est pas limité aux boutons de l’interface. Il peut construire POST, DELETE ou un chemin différent ; le serveur doit vérifier chaque demande selon ses propres règles.

Rejet et état

Tester une méthode refusée doit vérifier le non-effet. Un contrôle trop tardif peut laisser un effet interdit. Après une méthode refusée, vérifiez statut et état durable. Une réponse 405 produite après une mutation ne satisfait pas la frontière attendue, même si l’interface n’affiche aucun succès.

Atelier guidé : lire, expliquer et vérifier le code

GET /lab/reservations/42/cancel HTTP/1.1
Host: booking.example.test

Contrat du laboratoire : cette requête annule réellement la réservation.

Le contrat précise que le GET annule réellement une réservation. Le défaut concerne donc sa sémantique, pas seulement son nom de chemin. Déplacez la mutation vers un parcours explicite puis vérifiez méthodes refusées, autorisation sur l’objet et absence d’effet en cas de rejet.

Le verbe est précisément prévu pour une lecture sûre. Le chemin ne prouve pas les droits. Le canal ne supprime pas l’effet métier. Crawlers et préchargements peuvent demander un GET sans cette intention.

Travail pratique : Établissez les méthodes d’un portail de réservation puis essayez une consultation et une annulation avec les méthodes autorisées et refusées.

Critères de correction : Ajoutez des tests de routage pour les méthodes incorrectes et contrôlez l’absence d’effet de bord. Pour une requête valide, testez séparément acteur non autorisé, réservation inexistante et transition métier interdite.