A situação com o uso de códigos de resposta HTTP pode ser colocada em pesos e medidas: é o que acontece quando os bem intencionados desenvolvedores da especificação se deparam com uma realidade brutal. Mesmo com duas realidades brutais.
Conforme discutimos no Capítulo 10 , um dos objetivos dos erros semânticos é ajudar o cliente a entender o que causou o erro. No desenvolvimento da especificação HTTP (em particular, RFC 7231 ), esse objetivo foi obviamente um dos principais. Além disso, as limitações arquitetônicas do REST, conforme descrito por Fjelding em sua tese , sugerem que não apenas os clientes devem entender a semântica do erro, mas todos os agentes de rede (proxies) entre cliente e servidor em uma arquitetura "em camadas". E, de acordo com isso, a nomenclatura dos códigos de status HTTP descreve em grande detalhe quase todos os problemas que podem acontecer com uma solicitação HTTP: valores de Accept-*
cabeçalho inválidos , ausentesContent-Length
, método HTTP não compatível, URI muito longo e assim por diante.
Mas com o que o RFC não ajuda em nada - é com a questão, o que exatamente o cliente ou proxy deve fazer com um erro. Como discutimos, os bugs podem ser recuperáveis ou não recuperáveis. Se os erros forem fatais, os clientes em geral não se importam com toda essa salsa com códigos de status e cabeçalhos, e mais ainda com proxies intermediários. Para isso, na verdade, três códigos seriam suficientes:
400
para erros persistentes (se você apenas repetir a solicitação, o erro não irá a lugar nenhum);404
para um status de incerteza (repetir uma solicitação pode dar um resultado diferente);500
para problemas do lado do servidor, além de um cabeçalhoRetry-After
para permitir que o cliente saiba quando voltar.
Nota lateral : a propósito, preste atenção ao problema de design de especificações. Por padrão, todos os 4xx
códigos não são armazenados em cache, exceto: 404
, 405
, 410
, 414
. Não temos dúvidas de que isso foi feito com boas intenções, mas suspeitamos que o número de pessoas que conhecem essa sutileza é aproximadamente igual ao número de editores da especificação. Como resultado, temos muitas situações (o autor pessoalmente calculou as consequências de uma delas) em que 404
-ki foi retornado erroneamente, mas o cliente os armazenou em cache, estendendo assim o fakup por um tempo indefinido.
— , - - . , 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
; - , . - ( );
- , -, , .
- HTTP- , HTTP (..
, , #3 .
- Este texto foi escrito como parte da preparação da futura seção sobre a API HTTP para meu livro, o trabalho está sendo feito no GitHub .
A versão em inglês do mesmo texto está aqui .
Eu ficaria muito grato se alguém vasculhasse no reddit, eu mesmo, de acordo com as regras do reddit, não posso.