My two cents. I tend to agree me too that it's bad...

# arrow

[acando86]

My two cents. I tend to agree me too that it's bad design. null should not be used as a valid value IMO (not in the api response, not in json, not in code). null doesn't convey lot of information. if null is used to express something, chances are there are more explicit ways to encode that information semantically and in a more type-safe way (if option alone is not enough to express all the possible scenarios), instead of appending a meaning to the null value (for instance, ADTs etc). Close to the DB layer (in the code) it might make sense to store raw null values, but in between a db and the api response i would expect a number of mapping layers and business logic where relying on a specific meaning of null values is not necessary and maybe (IMO) not even advisable.

[rrader]

If null is not a valid value, then how will be if on registration form, user can set his birthday, but this is not mandatory, what value should it has in json?

[tmg]

literally nothing. Just send the json without that field.

[tmg]

if the data is not there, simply don't send it.
If there is some meaning to a null, use something explicit instead of null.

[rrader]

so, we have a nullable column in database "birthday", so we have 3 cases,
1. send a date
2. send null, so user want to remove the date
3. send nothing, how will be? we can not modify the data, but how in code we will know that user sent nothing? we can not use null, it has some meaning already

[tmg]

I see, using rest:
Either using PUT instead of patch (simplifies every single thing, specially if your BE and FE are separated codebases), or having that field be an optional instead of plain value, or having "birthday" being a subresource, so you can just DELETE, or using RPC instead of REST. I guess for some profile service rest is better.

[rrader]

so, or you do a PUT(update entire resource), or we should have an endpoint for each property, do you think this simply the API?

[pakoito]

@rrader you are modeling your request such as the received data has to be the final value. If instead you modelled your data as a set of transformations to apply to your model you’d avoid that issue.

[pakoito]

i.e. a different message for updating to empty and removing

[pakoito]

{
“op”: “delete”,
“value”: “ohno”
}


{
“op”: “update”,
“value”: null
}

[pakoito]

first one ignores value, second one sets it to null

[pakoito]

you can add validation at the edges of the layer, i.e. updates cannot be null, just empty string

[pakoito]

the point is using sealed operations over the network rather than ad-hoc semantics based off convention

[rrader]

Well, it is an approach, but it is not REST, and for me this looks ugly, this also is not supported by OpenAPI/Swagger, so I have to change all my tools

[pakoito]

it isn’t rest to have these shared semantics between missing field and null field, which is the cause of your pain

[pakoito]

rest, same as agile, has been overloaded to mean whatever’s convenient for some stakeholders

[rrader]

if it is not REST, than what is PUT & PATCH in REST?

[pakoito]

I’ve had rest services where everything was POST, so I don’t really know what true rest is really

[rrader]

in REST you work with resources, in your approach you work with operations

[pakoito]

your problem is not as uncommon as to not have been solved by a rest service before

[pakoito]

yes but rest doesn’t tell you whether a null on a json field is the same as a missing field

[rrader]

I solved it in JavaScript/TypeScript, there you have 2 values null and undefined

[pakoito]

and Java isn’t dynamic enough to know either, so you have to fall back to custom de/serializer to add semantics

[rrader]

why? you have types, you have Optional and you can have Undefined

[rrader]

that's it

[pakoito]

I’m aware, on my day to day I work on Flow (as in, developing flow itself), and null/undefined desambiguation is still an issue decades later for anyone that’s not a full-time JS developer

[pakoito]

closed objects is a good solution around it, but safety blows out of the window with these APIs where undefined and null have different semantics ;_____;

[rrader]

yes, because they are not types, just like null in java, but it is solved by a class Optional

[pakoito]

Optional<A?> is a solution

[pakoito]

you still need a custom deserializer

[pakoito]

and that’s what gives you the semantics

[pakoito]

you could implement it the other way around, where None means you received a null, and a Some(null) means you didn’t receive a field 😄

[pakoito]

you shouldn’t, but you could

[pakoito]

the point is that you’re not giving the semantics yourself

[pakoito]

and at that point you could just do

[pakoito]

sealed class OptionalValue<A> { 
  inline class Available(val value: A) 

  object Missing: Value<Nothing>

  object Disabled: Value<Nothing>
}

[pakoito]

and be explicit about it

[rrader]

my point is to have to classes Optional & Undefined that are explicit

[pakoito]

what do you think about the sealed class above?

[pakoito]

so you now have different semantics for missing field, disabled field, and “zero” values like 0 and ""

[pakoito]

without the need for convention

[rrader]

it is also a solution, but is harder to generate documentation from it

[pakoito]

KDoc

[pakoito]

this is on your client

[pakoito]

not on your swagger

[rrader]

I don't get it, I just propose to add a class, same as you, why my solution is not good?

[pakoito]

Undefined could work as a typealias for Option, you’re right

[pakoito]

my concern is being explicit

[pakoito]

I prefer to document using types rather than comments

[rrader]

in my case
1. Undefined<String> - optional & non-nullable
2. Undefined<String?> - optional & nullable
3. String - required & non-nullable
4. String? - required & nullable

[pakoito]

if I receive an OptionalValue the compiler forces me to handle the case where a value comes as null even when it’s not supposed to

[rrader]

that's it

[rrader]

yes it is documented by types

[rrader]

is it easy to generate swagger from it

[pakoito]

yeah, and you enforce it as deserialization

[pakoito]

else the data is malformed

[pakoito]

and you throw or return an either or an option or something

[pakoito]

my solution was for when you don’t enforce anything at deserialization

[pakoito]

which may be overkill

[pakoito]

😛

[rrader]

if you do not enforce that, than is hard to generate a correct swagger from it

[rrader]

BTW, this will also help in multi-platform for JS

[pakoito]

JS is enforcing you to use dynamic types so they can just spread network results on existing objects

[pakoito]

so they’re not really helping you be multi-platform at all

[rrader]

but interoperability? how will be if from js will be sent undefined value?

[pakoito]

if you send a sealed type it’ll work the same as TS’s enum types (IIRC), or any other runtime desambiguation that’s done in Redux on vanilla JS

[pakoito]

it’s not rest

[pakoito]

you’re right, so no swagger etc

[pakoito]

so you’re stuck with JS-first endpoints 😄

[rrader]

🙂

[pakoito]

now it’s when I shill for GraphQL, but I’m on holidays hahaha

[rrader]

this will also help in GraphQL https://medium.com/workflowgen/graphql-mutations-partial-updates-implementation-bff586bda989 😄