When there is no value assigned to a property, should it be returned as null or REST API should entirely skip such properties?
Consider an example of user object which has first_name and last_name. (In the below example, last_name need not be an empty string specifically. Consider it was never received from the end user.)
{
first_name: "Bob",
last_name: "",
}
Now since the client is aware of User schema, should last_name be returned or simply dropped from response so that client can automatically set a default value.(i.e empty string "")
In case null has to be returned, does it make sense to return null when it has got a special meaning in some cases.(i.e null means something and different from undefined)
My personal opinion to this would be to skip/omit the field, if no data present. If you would had to send hundreds of MB in this JSON then it would count a lot.
Also don't forget that your client should always have in mind and CHECK the data coming from the API up to a point. To check if a key exists in an array of keys is most easy in numerous programming languages out there.
Having in mind that you should validate the type of the information that comes from the API (int,string, object etc), it would save that part, if the key not exists in the response.
If by any chance you need a key to have a null value if not present in the API response, the above does not mean that you can not add it when you validate the API response. You still would have LESS things to compute, making this more efficient.
undefined should not be intentionally used if you want to express a missing value. For that we have null. The definition of... well nothing.
Im pretty sure thats why rfc4627 includes null.
JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays).
https://www.rfc-editor.org/rfc/rfc4627
It also indicates that you intentionally emitted null and that the value is not missing due to an internal error.
In the end this strongly depends on who is consuming this API.
If they know the specs, i think it's ok to go with undefined
It all depends on how you define your schema for the API. For example, if Swagger is used to define the API schema(spec), it allows you to specify the required fields that have to be present leaving rest of the fields optional. For example, in the below Error object, code and message fields always have to be returned by the service as they are defined as required. Client using this schema would always expect these fields and would program accordingly.
schemas:
# Schema for error response body
Error:
type: object
properties:
code:
type: string
message:
type: string
required:
- code
- message
So if lastname is defined as required in your API specification then never allow the user to enter a blank value in the first place. But in a case where the user is allowed to NOT enter any value in the field lastname, define your API spec. in a way where lastname is optional. If lastname is optional, then have the field populated in the response when there is value present else don't return the field in the response.