Feda /dev/ - No Javascript allowed

Si buscas recursos aplicando filtros y demás en la request, 200 con array vacío a mi me parece bien

Si quieres recibir un recurso único por id por ejemplo y no existe 404

#54001wdaoajw:

Si algo te devuelve un 404 es que TU estás haciendo algo mal

Si algo te devuelve un 404 es que has ido a buscar algo que no existe. Eso no es un error igual que no es un error abrir la nevera buscando leche y que no haya, el error sería no poder abrir la nevera o que la nevera no existiera. Abrirla y no encontrar leche es un proceso que se ha llevado a cabo correctamente pero que no ha devuelto nada.

Y eso no es un error.

#54004 El propio estándar llama a todos los 4xx como error

https://www.rfc-editor.org/rfc/rfc9110.html#name-client-error-4xx

Semánticamente se considera error 4xx cuando el propio acto de buscar algo que no existe está mal de por sí. Un ejemplo más acertado en mi opinión sería buscar calcetines en la nevera. Es un "client error" en el sentido de "qué coño haces buscando calcetines en la nevera?".

Tu ejemplo de la leche para mí sería un 2xx con un array vacío.

#54011 No estoy de acuerdo, el 204 lo devolverías si la respuesta no tuviera contenido pero todo ha ido ok. Con el 200 y un array vacío, dejas claro que hubo respuesta pero que no tiene datos.

#54013 es que el que suponga un problema o no es lógica de negocio... si tú haces una llamada, la llamada se recibe correctamente, y se devuelven los datos de esa llamada (que están vacíos), no veo porqué vas a devolver otra cosa que no sea un 2xx.

Otro tema es que los datos estén vacíos porque algo pete.

#54017

ningún componente o servicio ha fallado, ergo eso no es un error.

Es que eso sería un 5XX xd

#54018 O un 404 porque le has pasado un campo mal formado.

#54019 Devolver un 200 cuando no has encontrado algo que buscabas, muy correcto todo XD

La explicacion creo que ya la di en su dia, porque es un error comun, veo que todos lo cometeis, estais mezclando la capa de APPLICATION con la de NETWORKING.

Si te devuelve un 200 por HTTP, solo significa que hay bytes en el body, nada mas.

Desde el punto de vista de tu negocio, que puede estar "varias capas" por encima de ese GET HTTP, si esto esta bien o mal es otro tema. Podeis tener un mobil haciendo una peticion a una CDN, que falla y va a un balanceador que luego redirecciona a un servidor web, que este a su vez hace varias queries a distintas db (que pueden estar de nuevo cacheado y tener mi historias) y todo al final, te devuelve un status. Toda esta pipeline que devuelva un 200 se basa en que NETWORK funcione, el tcp, y que el contenido sea correcto APPLICATION.

Mi recomendacion simplemente es tener esto SIEMPRE presente y no mezclar applicacion con network nunca, desde el punto de vista de una cache, si recibe datos de la db y te lo devuelve eso es un 200 no? eres tu como programador quien construye encima.

En su dia me lei varias veces todo el protocolo http y status code y vereis que son muy especificos con esto de "transmision" y "network".

Hey chavales, ¿conocéis algún modelo ligerito comparador de textos para plagios?

#54026 Yo me refería a lógica de negocio. Me parece bien que el protocolo meta un not found en el saco de errores, no me afecta. Lo que sí me jode es que después llegue un PO y diga "tenemos un 15% de errores en las llamadas al servicio" cuando en realidad son todo not founds que recibimos del servicio al que consultamos para buscar las cosas.

Que un tío entre a la app y no encuentre un item no tiene por qué ser un error, por eso he puesto el ejemplo de Netflix. Me la pela que mi servicio lo reciba y lo considere un error, yo no debo loggear un not found como error si en la lógica de negocio se contempla que el contenido sea perecedero y en algún momento dado se vaya a buscar y haya desaparecido.