airbyte-api: add jackson model annotations to remove null values from responses

[alafanechere]

What

Our current server responses do not comply with our Open API spec.
Our server responses might return null value for fields that are not required and not declared as nullable in the Open API Spec.
This leads to failure of responses validation on generated API client.

How

• Add a Jackson annotation to generated API model to remove null fields on JSON response serialization in airbyte-api/build.gradle
• Remove nullable = true properties on the open API spec

🚨 Impact 🚨

This change will remove all null value fields from API responses. Even required field with null values will be removed. I'm not sure that it's a problem as if a field is required it means that it should not be null.

Other approaches I considered

@pmossman kindly suggested an approach here to perform some null check before assigning a value to the API model. I tried this approach but found the problem resides in Jackson/jaxrs: if a value on a model is not set it fallbacks to null and the null value is serialized in the JSON.
After finding this issue on the OpenApi generator repo I implemented the model level with annotation approach suggested by the contributors. As my current knowledge of java backend API (JAX-RS, Jackson etc.) is quite limited I might sure that I understand the mapper leve approach suggested on the issue l

[jdpgrailsdev]

[cgardens]

The @JsonInclude annotation contains below two values:
Include.NON_NULL: Indicates that only properties with not null values will be included in JSON.
Include.NON_EMPTY: Indicates that only properties that are not empty will be included in JSON.

How did you decide between NON_NULL and NON_EMPTY? @jdpgrailsdev any opinion on which would make more sense here? My mental model is that we want the following:

User:
  type: object
  properties:
    firstName:
      type: string
    lastName:
      type: string

I think we want this:

// object in memory => serialized object
{ firstName: "charles" } => { firstName: "charles" }
{ firstName: "charles", lastName: null } => { firstName: "charles", lastName: null }

I think the change you are making does this:

{ firstName: "charles" } => { firstName: "charles" }
{ firstName: "charles", lastName: null } => { firstName: "charles" }

The behavior before you change is this, right? Which we do not like.

{ firstName: "charles" } => { firstName: "charles", lastName: null }
{ firstName: "charles", lastName: null } => { firstName: "charles", lastName: null }

Basically, my sense is fields that are not set should not be serialized, but fields that are set to null values should be serialized, but my intuition could be off on this one. I can see an argument for the way you have done it.

[lmossman]

I'm not sure if it is possible with these annotations, but it seems like the ideal behavior would be that fields with nullable: true are included in the serialized JSON if they are explicitly set to something (either null or a real value), and they are not included if they are not set. But fields that do not have nullable: true should only ever be included in the serialized JSON if they are set to a non-null value, and they should not be included in the serialized JSON if they are set to null.

This behavior would always keep the openAPI spec consistent with the behavior of the API, while still allowing us to explicitly set fields to null when needed (if they are nullable)

[cgardens]

derp. agreed with what lake said. if we need it to be nullable then we should set it as such. okay. i think the implementation in this PR make sense.

[alafanechere]

Thank you @cgardens for the example! They are correct.

I think we want this:

// object in memory => serialized object
{ firstName: "charles" } => { firstName: "charles" }
{ firstName: "charles", lastName: null } => { firstName: "charles", lastName: null }

This is ideally what we want but I don't think it's achievable. When we create a model instance (from generated classes) the model attribute default to null in JAX-RS. It means that if we don't set the attribute on initialization the model instance will still have a null value for non-set attributes. So the default behavior will be:

// init params -> model instance in memory -> serialized json
{ firstName: "charles" } => { firstName: "Charles", lastName: "null" } =>  { firstName: "Charles", lastName: "null" } 
{ firstName: "charles", lastName: "null" } => { firstName: "Charles", lastName: "null" } =>  { firstName: "Charles", lastName: "null" } 

The change I made with the annotation leads to the following:

// init params -> model instance in memory -> serialized json
{ firstName: "charles" } => { firstName: "Charles", lastName: "null" } =>  { firstName: "Charles" } 
{ firstName: "charles", lastName: "null" } => { firstName: "Charles", lastName: "null" } =>  { firstName: "Charles"} 

Jackson cleans the object but without extra logic coming from the OpenAPI spec. It means that even if we set nullable = true on the lastName attribute we won't end up with a null value in the payload.
It answers @lmossman's question:

I'm not sure if it is possible with these annotations, but it seems like the ideal behavior would be that fields with nullable: true are included in the serialized JSON if they are explicitly set to something.

This is not possible with this implementation.

@cgardens @lmossman @jdpgrailsdev I would like to know if you are ok with this and want you to be aware that with this change the nullable = true won't be of any effect in the Open API spec. I am under the impression it is an acceptable compromise at the moment as we are not using this property but we might want to find a more flexible solution in the future. I don't know what this solution could be but it might be changing the generator from jaxrs-spec to another like spring 🤔

[lmossman]

Got it, it sounds like we can't get the ideal behavior we want with the current libraries we are using then. In that case, especially since it seems we aren't currently using nullable fields, I think your current implementation is acceptable.

@alafanechere I think it would be helpful to add a comment for this line that summarizes what we discussed here, to help explain why we are setting it to NOT_NULL and what that means for nullable fields.

[lmossman]

As I mentioned in the other comment thread, I think we should add a comment explaining why we are using the NOT_NULL annotation and what consequences that has. But otherwise this looks good to me

[alafanechere]

As I mentioned in the other comment thread, I think we should add a comment explaining why we are using the NOT_NULL annotation and what consequences that has. But otherwise this looks good to me

I added the comment 😄