2.2. Gestion des erreurs
2.2. Gestion des erreurs
Il existe plusieurs conditions connues dans lesquelles une requête PATCH peut échouer.
Document de correctif mal formé (Malformed patch document): Lorsque le serveur détermine que le document de correctif fourni par le client n'est pas correctement formaté, il DEVRAIT (SHOULD) renvoyer une réponse 400 (Bad Request). La définition de mal formaté dépend du document de correctif choisi.
Document de correctif non supporté (Unsupported patch document): Peut être spécifié à l'aide d'une réponse 415 (Unsupported Media Type) lorsque le client envoie un format de document de correctif que le serveur ne prend pas en charge pour la ressource identifiée par le Request-URI. Une telle réponse DEVRAIT (SHOULD) inclure un en-tête de réponse Accept-Patch comme décrit dans la section 3.1 pour informer le client des types de médias de document de correctif pris en charge.
Requête non traitable (Unprocessable request): Peut être spécifiée avec une réponse 422 (Unprocessable Entity) ([RFC4918], section 11.2) lorsque le serveur comprend le document de correctif et que la syntaxe du document de correctif semble valide, mais que le serveur est incapable de traiter la requête. Cela peut inclure des tentatives de modification d'une ressource d'une manière qui rendrait la ressource invalide; par exemple, une modification d'un document XML bien formé qui le rendrait non bien formé. Il peut également y avoir des erreurs plus spécifiques comme "État conflictuel (Conflicting State)" comme mentionné ci-dessus. Dans de tels cas, le serveur PEUT (MAY) inclure des informations d'erreur dans le corps de la réponse afin que l'utilisateur puisse déterminer ce qui ne va pas avec la requête de correctif.
Ressource non trouvée (Resource not found): Si la ressource à laquelle le client tente d'appliquer le correctif n'existe pas et que le serveur ne prend pas en charge la création de nouvelles ressources avec PATCH, le serveur renvoie un code d'état 404 (Not Found).
État conflictuel (Conflicting state): Si la requête est correctement formée et que le serveur prend en charge le type de média utilisé dans le document de correctif, mais que le serveur est incapable d'appliquer le correctif car l'état de la ressource est en conflit avec le correctif ou le correctif créera un conflit (par exemple, un correctif qui tente d'ajouter un champ conflictuel, ou une requête conditionnelle qui échoue), le serveur renvoie un code d'état 409 (Conflict). Le serveur DEVRAIT (SHOULD) inclure suffisamment d'informations dans le corps de la réponse pour que le client reconnaisse la source du conflit.
Modification conflictuelle (Conflicting modification): Si la requête est correctement formée et que le serveur prend en charge le type de média, mais que le correctif ne peut pas être appliqué à la ressource car la ressource a changé par rapport à l'état attendu (par exemple, la requête conditionnelle a échoué, un ETag fort ne correspond pas à la ressource actuelle), le serveur renvoie un code d'état 412 (Precondition Failed).
Modification simultanée (Concurrent modification): Les requêtes simultanées pour modifier une ressource avec PATCH peuvent avoir des résultats imprévisibles si les formats de correctif utilisés exigent que le client travaille à partir d'un document de base sous-jacent (base document). Ainsi, une requête PATCH peut échouer si des mises à jour simultanées provoquent un conflit. Tous ces risques de modification simultanée s'appliquent à toute interaction où plusieurs parties apportent des modifications à la même ressource. La méthode PATCH n'introduit pas de risques uniques, mais mérite d'être soulignée dans cette section.
Note: Pour toutes les réponses, le serveur peut inclure des informations d'erreur dans le corps de la réponse afin que le client puisse déterminer ce qui s'est mal passé ou quoi faire ensuite.