18

Tengo un recurso como este sales/customers/{customerno}. Si un cliente envía una solicitud PUT a este recurso, devolvería 400 - Solicitud incorrecta si el xml en el cuerpo de la entidad no es xml válido. Pero, ¿qué sucede si el xml es válido, pero el contenido del xml no es válido? Digamos, por ejemplo, que el cliente está tratando de actualizar el PostCode de los clientes y está proporcionando un PostCode que no es válido. ¿Es correcto devolver 400 - Solicitud incorrecta en este caso, o es otro código http que debería haber usado?REST - Cuándo utilizar 400 ("Solicitud incorrecta")

Respuesta

24

De Wikipedia's List of HTTP Status Codes:

400 Bad Request: La solicitud no puede ser satisfecha debido a la mala sintaxis.

En este caso, su cliente le envió una carga XML que tenía un código postal no válido, que es una forma de sintaxis no válida; por lo tanto, enviar un 400 Bad Request es un código de error apropiado para devolver en esta situación.

Además, Wikipedia cita RFC-4918 como un recurso sobre este tema. A partir de este documento, encontrará la siguiente información:

servidores pueden rechazar las solicitudes cuestionables (a pesar de que que consisten XML bien formado), por ejemplo, con un (Bad Request ) y el código de estado 400 un cuerpo de respuesta opcional que explica el problema .

Debido a que su solicitud está bien formado (el XML no es malo, simplemente contiene información semánticamente incorrecto) que puede rechazar el contenido con código de estado 400. La palabra *may* sugiere que hay otras opciones.

Si bien podría estar tentado a usar el código de estado 422, esto no sería correcto en esta situación, ya que el código postal no válido no cumple los criterios para ser un error semántico. Lea a continuación ...

De Wikipedia:

422 Entidad no procesable (WebDAV; RFC 4918): estaba bien formada La solicitud pero no pudo ser seguido debido a errores semánticos.

Además, aquí hay algunas definitions to assist in the interpretation of status code 422:

  • Los errores de sintaxis se producen durante el análisis del código de entrada, y son causadas por declaraciones incorrectas gramaticalmente. Los errores típicos pueden ser un carácter ilegal en la entrada, un operador faltante, dos operadores en una fila, dos declaraciones en la misma línea sin intercalar el punto y coma, paréntesis desbalanceados, una palabra reservada fuera de lugar, etc.

  • Se producen errores semánticos durante la ejecución del código, después de haber sido analizado como gramaticalmente correcto. No tienen que ver con cómo se construyen las declaraciones, sino con lo que significan. Cosas tales como tipos o tamaños de variables incorrectos, variables inexistentes, subíndices fuera de rango, y similares, son errores semánticos.

Su código postal no válido no es ni un error de sintaxis, ni un error semántico; por lo tanto, es razonable descartar el código de estado 422 como una opción.

Para responder a su pregunta, el código de estado 400 es apropiado; Sin embargo, es posible que tenga otras opciones también.

+0

Y las otras opciones son? –

+2

Encontré esto útil, pero estoy un poco confundido por la conclusión. Entiendo que hay una definición de "semántica" en la informática que difiere de su uso general. Fuera de la ciencia de la computación, un código postal no válido podría llamarse un error semántico en este contexto. Sospecho que tienes razón en que el RFC lo entendía específicamente en el sentido de la ciencia de la computación, pero ¿qué tan útil podría ser tal error? De hecho, ¿cómo podría ser un error * cliente * para nada? – Semicolon

+0

@Semicolon - Según tengo entendido, si el XML estaba bien formado pero el código postal estaba fuera de rango, cumpliría con la definición en el último punto. En los Estados Unidos, 123456 sería un código postal malo, por ejemplo, pero no sería un XML no válido. Un error que diga "400 Bad Request - Por favor ingrese un código postal válido" podría ser útil si se devuelve al cliente. Espero que esto ayude. – jmort253

17

La versión revisada de la especificación HTTP encontró here ha actualizado la redacción para tratar de evitar esta confusión, ya que 400 se limita solo a las solicitudes malformadas.

7.4.1. 400 Solicitud incorrecta

El servidor no puede o no procesará la solicitud, debido a un error del cliente (por ejemplo, sintaxis mal formada).

+0

¿El código 400 también incluye id's en la carga útil de la que el usuario no es propietario de los recursos? – Elisabeth

+0

@Elisabeth No estoy seguro de entender completamente su situación, pero creo que la respuesta es sí. –

+0

El escenario es una carga con algunos Id de clave externa que pertenecen a otro usuario. Eliminar esos id's en el servidor eliminaría los recursos de otro usuario. Eso sería realmente malo. – Elisabeth

Cuestiones relacionadas