Cuando no hay un valor asignado a una propiedad, ¿debería devolverse como nulo o la API REST debería omitir por completo dichas propiedades?
Considere un ejemplo de objeto de usuario que tiene nombre y apellido. (En el siguiente ejemplo, last_name no necesita ser una cadena vacía específicamente. Tenga en cuenta que nunca se recibió del usuario final).
{ first_name: "Bob", last_name: "", } Ahora, dado que el cliente conoce el esquema del usuario, ¿debe devolverse last_name o simplemente eliminarse de la respuesta para que el cliente pueda establecer automáticamente un valor predeterminado (es decir, una cadena vacía "" )
En caso de que se deba devolver nulo, ¿tiene sentido devolver nulo cuando tiene un significado especial en algunos casos (es decir, null significa algo y es diferente de undefined )
Mi opinión personal sobre esto sería omitir/omitir el campo, si no hay datos presentes. Si tuviera que enviar cientos de MB en este JSON , contaría mucho.
Además, no olvide que su cliente siempre debe tener en cuenta y VERIFICAR los datos provenientes de la API hasta cierto punto. Comprobar si existe una clave en una matriz de claves es más fácil en numerosos lenguajes de programación que existen.
Teniendo en cuenta que debe validar el tipo de información que proviene de la API (int, cadena, objeto, etc.), guardaría esa parte, si la clave no existe en la respuesta.
Si por casualidad necesita que una clave tenga un valor nulo si no está presente en la respuesta de la API, lo anterior no significa que no pueda agregarla cuando valide la respuesta de la API. Todavía tendría LESS cosas para calcular, lo que lo haría más eficiente.
undefined no debe usarse intencionalmente si desea expresar un valor faltante. Para eso tenemos null . La definición de... pues nada. Estoy bastante seguro de que es por eso que rfc4627 incluye nulo.
JSON puede representar cuatro tipos primitivos (cadenas, números, booleanos y nulos) y dos tipos estructurados (objetos y matrices).
https://www.rfc-editor.org/rfc/rfc4627
También indica que emitiste null intencionalmente y que el valor no falta debido a un error interno.
Al final, esto depende en gran medida de quién consume esta API. Si conocen las especificaciones, creo que está bien ir con undefined
Todo depende de cómo defina su esquema para la API. Por ejemplo, si se usa Swagger para definir el esquema API (especificación), le permite especificar los campos obligatorios que deben estar presentes, dejando el resto de los campos opcionales. Por ejemplo, en el siguiente objeto de error, los campos de código y mensaje siempre deben ser devueltos por el servicio, ya que se definen como obligatorios. El cliente que usa este esquema siempre esperaría estos campos y programaría en consecuencia.
schemas: # Schema for error response body Error: type: object properties: code: type: string message: type: string required: - code - messageEntonces, si el apellido se define como requerido en la especificación de su API, nunca permita que el usuario ingrese un valor en blanco en primer lugar. Pero en el caso de que el usuario NO pueda ingresar ningún valor en el campo apellido, defina su especificación de API. de una manera donde el apellido es opcional. Si el apellido es opcional, complete el campo en la respuesta cuando haya un valor presente; de lo contrario, no devuelva el campo en la respuesta.