La situación con los códigos de respuesta HTTP se puede poner en los pesos y medidas: esto es lo que sucede cuando los desarrolladores bien intencionados de la especificación se enfrentan a la brutal realidad. Incluso con dos realidades brutales.
Como discutimos en el Capítulo 10 , uno de los objetivos de los errores semánticos es ayudar al cliente a comprender qué causó el error. En el desarrollo de la especificación HTTP (en particular, RFC 7231 ), este objetivo fue obviamente uno de los principales. Además, las limitaciones arquitectónicas de REST, como las describe Fjelding en su tesis , sugieren que no solo los clientes deben comprender la semántica del error, sino todos los agentes de red (proxies) entre el cliente y el servidor en una arquitectura "en capas". Y, de acuerdo con esto, la nomenclatura de los códigos de estado HTTP describe con gran detalle casi cualquier problema que pueda ocurrir con una solicitud HTTP: valores de Accept-*
encabezado no válidos , faltantesContent-Length
, método HTTP no compatible, URI demasiado largo, etc.
Pero con lo que el RFC no ayuda en absoluto, es con la pregunta, ¿qué debería hacer exactamente el cliente o el proxy con un error? Como comentamos, los errores pueden ser recuperables o no recuperables. Si los errores son fatales, entonces a los clientes en general no les importa un comino todo este perejil con códigos de estado y encabezados, y más aún los proxies intermedios. Para ello, de hecho, bastarían tres códigos:
400
para errores persistentes (si simplemente repite la solicitud, el error no irá a ninguna parte);404
para un estado de incertidumbre (volver a intentar una solicitud puede dar un resultado diferente);500
para problemas del lado del servidor más un encabezadoRetry-After
para decirle al cliente cuándo regresar.
Nota al margen : por cierto, preste atención al problema de diseño de la especificación. Por defecto, todos los 4xx
códigos no se almacenan en caché, excepto: 404
, 405
, 410
, 414
. No tenemos ninguna duda de que esto se hizo con buenas intenciones, pero sospechamos que el número de personas que conocen esta sutileza es aproximadamente igual al número de editores de la especificación. Como resultado, tenemos muchas situaciones (el autor personalmente analizó las consecuencias de una de ellas), en las que 404
-ki se devolvió por error, pero el cliente las guardó en caché, extendiendo así el fakup por un tiempo 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 fue escrito como parte de la preparación de la sección futura sobre la API HTTP para mi libro, se está trabajando en GitHub .
La versión en inglés del mismo texto está aquí .
Estaré agradecido si alguien lo busca en reddit, yo mismo no puedo de acuerdo con las reglas de reddit.