Problème de codes d'état HTTP

La situation avec les codes de réponse HTTP peut être mise dans les poids et les mesures: c'est ce qui se passe lorsque les développeurs bien intentionnés de la spécification sont confrontés à une réalité brutale. Même avec deux réalités brutales.

Comme nous l'avons vu au chapitre 10 , l'un des objectifs des erreurs sémantiques est d'aider le client à comprendre la cause de l'erreur. Dans le développement de la spécification HTTP (en particulier, RFC 7231 ), cet objectif était évidemment l'un des principaux. De plus, les limites architecturales de REST, telles que décrites par Fjelding dans sa thèse , suggèrent que non seulement les clients doivent comprendre la sémantique de l'erreur, mais tous les agents réseau (proxies) entre le client et le serveur dans une architecture «en couches». Et, selon cela, la nomenclature des codes d'état HTTP décrit en effet en détail presque tous les problèmes pouvant survenir avec une requête HTTP: valeurs d'en- Accept-*



tête invalides , manquantesContent-Length



, méthode HTTP non prise en charge, URI trop long, etc.

Mais avec ce que la RFC n'aide pas du tout - c'est avec la question, que doit faire exactement le client ou le proxy en cas d'erreur. Comme nous l'avons vu, les erreurs peuvent être récupérables ou non récupérables. Si les erreurs sont fatales, alors les clients ne se soucient généralement pas de tout ce persil avec des codes de statut et des en-têtes, et encore plus des proxys intermédiaires. Pour cela, en effet, trois codes suffiraient:

• 400
  
  
  
  pour les erreurs persistantes (si vous ne faites que répéter la demande, l'erreur n'ira nulle part);
• 404
  
  
  
  pour l'état d'incertitude (le fait de réessayer la demande peut donner un résultat différent);
• 500
  
  
  
  pour les problèmes côté serveur plus un en-tête Retry-After
  
  
  
  pour indiquer au client quand revenir.

Note latérale : en passant, faites attention au problème de conception des spécifications. Par défaut, tous les 4xx



codes ne sont pas mises en cache, à l' exception: 404



, 405



, 410



, 414



. Nous n'avons aucun doute que cela a été fait avec de bonnes intentions, mais nous soupçonnons que le nombre de personnes qui connaissent cette subtilité est approximativement égal au nombre d'éditeurs de la spécification. En conséquence, nous avons de nombreuses situations (l'auteur a personnellement analysé les conséquences de l'une d'entre elles), lorsque 404



-ki a été renvoyé par erreur, mais le client les a mis en cache, prolongeant ainsi le fakup pour une durée indéfinie.

— , - - . , 411 Length Required



. — . , :

• 400 Bad Request
  
  
  
  , . , , — ! , , — REST.

  
  
  
  
  
  
  

  NB: , 400
  
  
  
  , .. URI, , JSON .., 422 Unprocessable Entity



412 Precondition Failed
  
  
  
  . , .

  
  
  
  
  
  
  

• 403 Forbidden
  
  
  
  / . Forbidden
  
  
  
  -, :

  
  
  
  
  
  
  
  • — ;
  • — ;
  • — ;
  • — ;
  • — - .
  
  
  

  403
  
  
  
  , (, ) .

  
  
  
  
  
  
  

• 409 Conflict
  
  
  
  ;

  
  
  
  
  
  
  

• .

  
  
  
  
  
  
  

, / , — , 400



-, .

: , : ‘The response message will usually contain a representation that explains the status’. , , , , ( - ?), REST: , «» , .

, : - «» HTTP, . . Web - . , , , , , -. : , - — .

, . ¯\_(ツ)_/¯. — 401 Unauthorized



: WWW-Authenticate



— , , , , .. — Basic



(-, - Web 1.0, ). , , realm



- — . 401



— WWW-Authenticate



, , .

: - HTTP , ; ; - , . ( , , — , , , .) , , 200



-.

?

:

• REST RPC. - HTTP . :

  
  
  
  
  
  
  
  • 200 OK
    
    
    
    , — 200
    
    
    
    .
  • 500 Internal Server Error
    
    
    
    .
  
  
  

  400 Bad Request
  
  
  
  . , API Gateway;

  
  
  
  
  
  
  

• « » — , , , . ; — - . .
  
  NB: , : RPC- , , - - (, 403



429
  
  
  
  , - - , HTTP). , , , «» . ;

  
  
  
  
  
  
  

• . , :

  
  
  
  
  
  
  
  • HTTP- , HTTP (.. 406 Unacceptable



Accept-Language
    
    
    
    , , - );
  • , HTTP ( , ; ) — , - X-My-API-Error-Reason
    
    
    
    ;
  • , . - ( );
  • , -, , .
  
  
  

, , #3 .

- Ce texte a été rédigé dans le cadre de la préparation de la future section sur l'API HTTP de mon livre, des travaux sont en cours sur GitHub .

La version anglaise du même texte est ici .

Je serai reconnaissant si quelqu'un le fouille sur reddit, je ne peux pas moi-même selon les règles de reddit.