Sus datos devueltos deben reflejar la forma de los datos que se solicitan. Si solicitan la información de un usuario, y eso incluye un saldo de usuario como uno a uno y créditos que vencen como uno a muchos, debe incluir esas relaciones. Si no hay nada que incluir, llámelo específicamente con un nulo si es uno a uno para que el desarrollador sepa que "faltan datos aquí" y si es uno a muchos, devuelva una matriz vacía, como no había registros dependientes pero había un registro maestro.

Un punto final de ejemplo:

 /user/[id]/credits GET id: the user's id { user_balance: null | number, // o:o expiring_credits: credits[] // o:m }

De esta manera, la forma de los datos es siempre la misma para el desarrollador consumidor y no tendría que preocuparse por las claves de nivel superior que no existen en el objeto devuelto. Siempre estará allí y siempre será coherente con el tipo devuelto.

Si existe, será de este tipo. Si fuera una matriz, siempre será una matriz. Esto permite que las personas codifiquen según la forma de los datos, no según la posibilidad de la forma de los datos.

Siempre sería una buena práctica hacer que la estructura de respuesta json esté intacta para que el cliente no necesite entender si el atributo está vacío porque el atributo en sí se perdió debido a alguna autorización o si puede deberse a que no hay datos presentes.

Si el atributo está presente y no los datos están presentes en la matriz, se dará más claridad al usuario que llama que eliminar el atributo en sí.

¿Cuál es la opción ideal o mejores prácticas?

DESCANSO no le importa.

Lo que tiene aquí es una pregunta sobre el diseño del esquema, y específicamente si su expiring de créditos que vencen debe ser opcional u obligatorio.

Por ejemplo, OpenApi usa parámetros opcionales por defecto; su especificación debe "aceptar" explícitamente el uso de parámetros obligatorios (el campo "obligatorio" es opcional). Este patrón se aplica a los objetos de su esquema , al igual que a los parámetros de su URI (el campo "obligatorio" es opcional ).

La elección entre opcional y obligatorio puede afectarlo más adelante si descubre que necesita modificar el esquema y desea hacerlo de una manera que no rompa los clientes existentes. La comunidad XML exploró esta pregunta en el pasado, por lo que querrá ver sus conclusiones (y en particular políticas como debe ignorar y debe reenviar).

Nota : todo lo que digo aquí se basa en mi propia experiencia en el desarrollo de aplicaciones web y API.
En mi experiencia, enviar siempre una estructura estática al front-end o cualquier otra API o aplicación web o donde sea es mejor que no enviarlos en absoluto.
Es decir, si está trabajando en un proyecto y tiene que enviar sus datos al siguiente departamento implementado, debe tener un estándar para sus respuestas y eso significa que promete si, por ejemplo, envía algunos datos con 200 código de respuesta de /me/ url, seguramente tienes que prometer que siempre envías los campos ["username", "email"] . (incluso cuando son cadenas nulas o vacías) Esto hace que el otro departamento (que puede ser cualquier cosa) confíe siempre en las respuestas de su api.

 response = { user_balance: 20 expiring_credits : [] }

Así que esto es mejor.

No puedo pensar en ninguna buena razón para omitir un campo solo porque está vacío. Es posible que pueda guardar algunos bytes en la respuesta, pero ese es un argumento muy débil.

Por otro lado: omisión no es lo mismo que ausencia. Las API pueden devolver respuestas parciales :

La respuesta parcial le permite brindar a los desarrolladores de aplicaciones solo la información que necesitan.

fuente: Web API Design: The Missing Link

Con respuestas parciales:

api.example.com/user/1234 devuelve todos los campos de forma predeterminada:

 response = { user_balance: 20, expiring_credits : [ {object 1 }, {object 2} ] }

api.example.com/user/1234?fields=user_balance solo envía user_balance , omitiendo los créditos a punto de expiring credits incluso si existen créditos a punto de caducar:

 response = { user_balance: 20 }

La mejor práctica es enviar una matriz vacía. El motivo es que cuando alguien llama a su API y espera que el campo expiring_credits esté presente en la respuesta, si no lo envió porque está vacío, puede suponer que envió una solicitud incorrecta porque la matriz vacía es un valor válido.

response = { user_balance: 20 expiring_credits : [] }

La opción 2 es la mejor práctica por las siguientes razones

1. No tiene que escribir código adicional para manejar la situación indefinida . Esto simplemente generará una cuadrícula vacía.
2. Menos propenso a errores.
3. Ahora se confirma que el consumidor está bien, la API está proporcionando la respuesta correcta. Es solo que no hay créditos que expiring_credits a partir de ahora.
4. Mientras usa bibliotecas como Typescript, no tiene que mencionar un campo opcional.