HTTP status codes problem

The situation with HTTP response codes can be put in the weights and measures: this is what happens when the well-intentioned developers of the specification are faced with a brutal reality. Even with two brutal realities.

As we discussed in Chapter 10 , one of the goals of semantic errors is to help the client understand what caused the error. In the development of the HTTP specification (in particular, RFC 7231 ), this goal was obviously one of the main ones. Moreover, the architectural limitations of REST as described by Fjelding in his thesis suggest that not only clients must understand the semantics of the error, but all network agents (proxies) between client and server in a "layered" architecture. And, according to this, the nomenclature of HTTP status codes does indeed describe in great detail almost any problem that might happen with an HTTP request: invalid Accept-*



header values , missingContent-Length



, unsupported HTTP method, too long URI, and so on.

But with what the RFC does not help at all - it is with the question, what exactly should the client or proxy do with an error. As we discussed, bugs can be recoverable or non-recoverable. If the errors are fatal, then clients by and large do not give a damn about all this parsley with status codes and headers, and even more so intermediate proxies. For this, in fact, three codes would be enough:

• 400
  
  
  
  for persistent errors (if you just repeat the request, the error will not go anywhere);
• 404
  
  
  
  for an uncertainty status (retrying a request may give a different result);
• 500
  
  
  
  for server side issues plus a header Retry-After
  
  
  
  to tell the client when to come back.

Note : By the way, pay attention to the design issue of the spec. By default, all 4xx



codes are not cached, except: 404



, 405



, 410



, 414



. We have no doubt that this was done with good intentions, but we suspect that the number of people who know about this subtlety is approximately equal to the number of editors of the specification. As a result, we have many situations (the author personally raked through the consequences of one of them), when 404



-ki were returned erroneously, but the client cached them, thereby extending the fakup for an indefinite time.

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

- This text was written as part of the preparation of the future section on the HTTP API for my book, work is being done on GitHub .

The English version of the same text is here .

I will be grateful if someone fumbles it on reddit, I myself cannot according to the rules of reddit.