Problem mit HTTP-Statuscodes

Die Situation bei der Verwendung von HTTP-Antwortcodes kann in die Gewichte und Maße einbezogen werden: Dies geschieht, wenn die gut gemeinten Entwickler der Spezifikation mit einer brutalen Realität konfrontiert werden. Selbst mit zwei grausamen Realitäten.

Wie wir in Kapitel 10 besprochen haben , besteht eines der Ziele semantischer Fehler darin, dem Client zu helfen, zu verstehen, was den Fehler verursacht hat. Während der Entwicklung der HTTP-Spezifikation (insbesondere RFC 7231 ) war dieses Ziel offensichtlich eines der Hauptziele. Darüber hinaus legen die von Fjelding in seiner Dissertation beschriebenen architektonischen Einschränkungen von REST nahe , dass nicht nur Clients die Semantik des Fehlers verstehen müssen, sondern alle Netzwerkagenten (Proxys) zwischen Client und Server in einer "geschichteten" Architektur. Demnach beschreibt die Nomenklatur der HTTP-Statuscodes fast jedes Problem, das bei einer HTTP-Anforderung auftreten kann, sehr detailliert: ungültige Accept-*



Header- Werte , fehlenContent-Length



, nicht unterstützte HTTP-Methode, zu lange URI usw.

Aber mit dem, was der RFC überhaupt nicht hilft - es ist mit der Frage, was genau der Client oder Proxy mit einem Fehler machen soll. Wie bereits erwähnt, können Fehler wiederhergestellt oder nicht wiederhergestellt werden. Wenn die Fehler schwerwiegend sind, kümmern sich die Clients im Großen und Ganzen nicht um all diese Petersilie mit Statuscodes und Headern und noch mehr um Zwischenproxies. Dafür würden tatsächlich drei Codes ausreichen:

• 400
  
  
  
  bei dauerhaften Fehlern (wenn Sie nur die Anforderung wiederholen, wird der Fehler nirgendwo hingehen);
• 404
  
  
  
  für den Status der Unsicherheit (das Wiederholen der Anforderung kann zu einem anderen Ergebnis führen);
• 500
  
  
  
  Für serverseitige Probleme sowie einen Header Retry-After
  
  
  
  , der dem Client mitteilt, wann er zurückkehren soll.

: , . 4xx



, : 404



, 405



, 410



, 414



. , , , , , . ( ), 404



- , , .

— , - - . , 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 .

- Dieser Text wurde im Rahmen der Vorbereitung des zukünftigen Abschnitts über die HTTP-API für mein Buch geschrieben. Derzeit wird an GitHub gearbeitet .

Die englische Version des gleichen Textes ist hier .

Ich werde dankbar sein, wenn jemand es auf reddit fummelt, ich selbst kann nicht nach den Regeln von reddit.