Supongamos que desea obtener una lista de usuarios llamando GETa api/users, pero actualmente la tabla está truncada, por lo que no hay usuarios. ¿Cuál es la respuesta adecuada para este escenario: 404o 204?
Respondería con 200 y una colección vacía (no un cuerpo de respuesta vacío, sino una colección sin elementos dentro, esto se verá diferente según el formato devuelto)
toniedzwiedz
4
404 en este contexto probablemente sería más adecuado para 'tabla no encontrada'. Yo diría que devuelva una lista vacía.
@EJoshuaS No lo es. Ambas preguntas son mías y muy antiguas. Son similares pero no duplicados.
IMB
1
@EJoshuaS Obviamente no son duplicados. Esta pregunta se trata de /api/usersmientras se trata de la otra /api/users/1.
Franklin Yu
Respuestas:
231
Yo diría que tampoco.
¿Por qué no 404 (no encontrado)?
El código de estado 404 debe reservarse para situaciones en las que no se encuentra un recurso. En este caso, su recurso es una colección de usuarios . Esta colección existe pero actualmente está vacía. Personalmente, estaría muy confundido como autor de un cliente para su aplicación si tuviera un 200día y un404 al día siguiente solo porque alguien eliminó un par de usuarios. ¿Que se supone que haga? ¿Mi URL es incorrecta? ¿Alguien cambió la API y se olvidó de dejar una redirección?
El servidor ha cumplido la solicitud, pero no necesita devolver un cuerpo de entidad y es posible que desee devolver metainformación actualizada.
Si bien esto puede parecer razonable en este caso, creo que también confundiría a los clientes. Se 204supone que A indica que alguna operación se ejecutó correctamente y no es necesario devolver ningún dato. Esto es perfecto como respuesta a una DELETEsolicitud o tal vez para activar algún script que no necesita devolver datos. En el caso de api/users, normalmente espera recibir una representación de su colección de usuarios. Enviar un cuerpo de respuesta una vez y no enviarlo la otra vez es inconsistente y potencialmente engañoso.
Por qué usaría un 200 (OK)
Por las razones mencionadas anteriormente (coherencia), devolvería una representación de una colección vacía. Supongamos que está utilizando XML. Un cuerpo de respuesta normal para una colección de usuarios no vacía podría verse así:
y si la lista está vacía, podría responder con algo como esto (mientras sigue usando a 200):
<users/>
De cualquier manera, un cliente recibe un cuerpo de respuesta que sigue un formato determinado y conocido. No hay confusión innecesaria ni verificación de códigos de estado. Además, no se infringe ninguna definición de código de estado. Todo el mundo está feliz.
Puede hacer lo mismo con JSON o HTML o cualquier formato que esté usando.
Definitivamente de acuerdo. Y para el descanso, simplemente me gustaría enviar un código de estado de 200 con una matriz vacía: [].
Chad Johnson
Tiene sentido. No es necesario hacerlo más difícil. 404 sería confuso.
Witold Kaczurba
Supongamos API que describe las monedas en su bolsillo, con puntos finales: GET /singleCoin- devuelve una sola moneda al azar de su bolsillo, GET /severalCoins- devuelve algunas monedas de su bolsillo que puede agarrar de una vez. Digamos que ahora no tienes monedas en el bolsillo. Cuando lo pidas GET /singleCoin, obtendrás 404 Not Found, pero cuando lo pidas GET /severalCoins, obtendrás 200 OKcon la lista vacía []. Un hecho: no tiene monedas, se describe con diferentes respuestas, ¿por qué? Diría que es mejor conseguir siempre 404 Not Found, porque no hay monedas en tu bolsillo.
sempasha
1
@sempasha Depende de lo que quieras decir GET /severalCoins. Si ordena que GET /severalCoinsdebe devolver algunas monedas, entonces no debería ser 200 porque no está bien; el servidor no pudo proporcionar lo que el cliente deseaba. Porque /singleCoinesto es obvio porque el cliente quiere exactamente una moneda, ni más ni menos. Esto es lo mismo para /coins/7. En contraste con el /coinspunto final, los clientes típicamente no esperan una moneda, una moneda o varias monedas. Todos ellos son respuesta válida. Si no hay moneda, entonces esto es lo que quieren. Es como un emply List<Coin>en Java, en lugar de null.
Franklin Yu
15
Respondería uno de dos códigos dependiendo de la situación del tiempo de ejecución:
404 No encontrado)
Esta respuesta es bastante correcta si no tiene mesa. No solo una mesa vacía sino SIN MESA DE USUARIO. Confirma la idea exacta, sin recursos. Otras opciones son proporcionar más detalles POR QUÉ su tabla está ausente, hay un par de códigos más detallados, pero 404 es bastante bueno para referirse a una situación en la que realmente no tiene una tabla.
200 (OK)
Todos los casos en los que tiene una tabla pero está vacía o su procesador de solicitudes ha filtrado todos los resultados. Esto significa 'su solicitud es correcta, todo está bien, pero no coincide con ningún dato simplemente porque no tenemos datos o no tenemos datos que coincidan con su solicitud'. Esto debería ser diferente de la respuesta de negación de seguridad. También voto para devolver 200 en una situación en la que tiene algunos datos y, en general, se le permite acceder a la tabla pero no tiene acceso a todos los datos que coinciden con su solicitud (los datos se filtraron debido a la seguridad a nivel del objeto, pero en general se le permite solicitud).
404 significa recurso no encontrado. Pero el recurso existe. Y también, si la respuesta tiene estado 404. ¿Cómo puede saber que la lista de usuarios está vacía o llena?
'/ users' si está vacío debería devolver '200'.
'/ users / 1' si no se encuentra la identificación. debe devolver 404.
/api/usersmientras se trata de la otra/api/users/1.Respuestas:
Yo diría que tampoco.
¿Por qué no 404 (no encontrado)?
El código de estado 404 debe reservarse para situaciones en las que no se encuentra un recurso. En este caso, su recurso es una colección de usuarios . Esta colección existe pero actualmente está vacía. Personalmente, estaría muy confundido como autor de un cliente para su aplicación si tuviera un
200día y un404al día siguiente solo porque alguien eliminó un par de usuarios. ¿Que se supone que haga? ¿Mi URL es incorrecta? ¿Alguien cambió la API y se olvidó de dejar una redirección?¿Por qué no 204 (sin contenido)?
Aquí hay un extracto de la descripción del código de estado 204 por w3c
Si bien esto puede parecer razonable en este caso, creo que también confundiría a los clientes. Se
204supone que A indica que alguna operación se ejecutó correctamente y no es necesario devolver ningún dato. Esto es perfecto como respuesta a unaDELETEsolicitud o tal vez para activar algún script que no necesita devolver datos. En el caso deapi/users, normalmente espera recibir una representación de su colección de usuarios. Enviar un cuerpo de respuesta una vez y no enviarlo la otra vez es inconsistente y potencialmente engañoso.Por qué usaría un 200 (OK)
Por las razones mencionadas anteriormente (coherencia), devolvería una representación de una colección vacía. Supongamos que está utilizando XML. Un cuerpo de respuesta normal para una colección de usuarios no vacía podría verse así:
y si la lista está vacía, podría responder con algo como esto (mientras sigue usando a
200):De cualquier manera, un cliente recibe un cuerpo de respuesta que sigue un formato determinado y conocido. No hay confusión innecesaria ni verificación de códigos de estado. Además, no se infringe ninguna definición de código de estado. Todo el mundo está feliz.
Puede hacer lo mismo con JSON o HTML o cualquier formato que esté usando.
fuente
[].GET /singleCoin- devuelve una sola moneda al azar de su bolsillo,GET /severalCoins- devuelve algunas monedas de su bolsillo que puede agarrar de una vez. Digamos que ahora no tienes monedas en el bolsillo. Cuando lo pidasGET /singleCoin, obtendrás404 Not Found, pero cuando lo pidasGET /severalCoins, obtendrás200 OKcon la lista vacía[]. Un hecho: no tiene monedas, se describe con diferentes respuestas, ¿por qué? Diría que es mejor conseguir siempre404 Not Found, porque no hay monedas en tu bolsillo.GET /severalCoins. Si ordena queGET /severalCoinsdebe devolver algunas monedas, entonces no debería ser 200 porque no está bien; el servidor no pudo proporcionar lo que el cliente deseaba. Porque/singleCoinesto es obvio porque el cliente quiere exactamente una moneda, ni más ni menos. Esto es lo mismo para/coins/7. En contraste con el/coinspunto final, los clientes típicamente no esperan una moneda, una moneda o varias monedas. Todos ellos son respuesta válida. Si no hay moneda, entonces esto es lo que quieren. Es como un emplyList<Coin>en Java, en lugar denull.Respondería uno de dos códigos dependiendo de la situación del tiempo de ejecución:
404 No encontrado)
Esta respuesta es bastante correcta si no tiene mesa. No solo una mesa vacía sino SIN MESA DE USUARIO. Confirma la idea exacta, sin recursos. Otras opciones son proporcionar más detalles POR QUÉ su tabla está ausente, hay un par de códigos más detallados, pero 404 es bastante bueno para referirse a una situación en la que realmente no tiene una tabla.
200 (OK)
Todos los casos en los que tiene una tabla pero está vacía o su procesador de solicitudes ha filtrado todos los resultados. Esto significa 'su solicitud es correcta, todo está bien, pero no coincide con ningún dato simplemente porque no tenemos datos o no tenemos datos que coincidan con su solicitud'. Esto debería ser diferente de la respuesta de negación de seguridad. También voto para devolver 200 en una situación en la que tiene algunos datos y, en general, se le permite acceder a la tabla pero no tiene acceso a todos los datos que coinciden con su solicitud (los datos se filtraron debido a la seguridad a nivel del objeto, pero en general se le permite solicitud).
fuente
Si está esperando una lista de objetos de usuario, la mejor solución es devolver una lista vacía ([]) con 200 OK que usar una respuesta 404 o 204.
fuente
definitivamente devuelve 200.
404 significa recurso no encontrado. Pero el recurso existe. Y también, si la respuesta tiene estado 404. ¿Cómo puede saber que la lista de usuarios está vacía o llena?
fuente
Debe 200 OK con la lista vacía.
Por qué: tabla vacía significa que la tabla existe pero no tiene registros.
404 No encontrado significa que el punto final solicitado no existe.
fuente