Principled code generation from OpenAPI specifications. https://guardrail.dev/
1) on the server side, if there are response fields with a default, the server should always send those defaults rather than sending missing values, so the client's default-fallback machinery won't ever trigger.
2) on the client side, if there are request fields with a default, they'll be documented as such in the docs for the version of the client that the user is using, so they should be like "ok, i'm satisfied with default X, so i don't need to pass a different value". if the default value on the server side changes, sure, the "old" default will still get passed by old clients, but presumably the people using those clients know that and are ok with it.
3) on a somewhat higher level, if customers are using guardrail-generated clients and servers, defaults will never come into play on deserialization anyway, because guardrail-generated clients will always send default values in requests, and guardrail-generated servers will always send default values in responses (that is, they'll never be null or missing). the only time default values come into play on deserialization will be when someone is using a hand-rolled client, or is using curl or something to test things
required=false,nullable=true requires it
ObjectMapper from the route class
@Inject one into the class...)
required=true,nullable=false properties when a default is present. like, i could see the argument that a client could actually leave that property out entirely, because the server should know about the default, and automatically fall back (so these sorts of properties automatically get 'demoted' to required=false,nullable=false). but maybe you want to think of it as more of a "UX default": the server will barf if you don't include it, and the default there is mainly to make it so the user of the client doesn't have to explicitly fill in the property (because the client can do it for them).
At the risk of making the wrong gut decision here, but required=true,nullable=false with a default should have the default injected by the server before the user sees it, regardless of presence in the actual wire encoding. If that means translating that into required=false,nullable=false then so be it.
The expectation would then be that removing the default from the spec would cause the generated code to change and a compiler error to be emitted.
i'm still struggling a bit, though. the more i think about it... well, take the most "flexible" case, required=false,nullable=true. that's our tri-state of absent, null, or present. if i think about reflecting the intent of the user of the client, i would say that leaving things as absent would mean the client is saying "i don't care", and the server should assume the default value. if the client explicitly sends null, then i would think the client is saying "really, i mean no value here", and the server should not substitute the default.
if we accept that as reasonable -- maybe we won't, but let's assume we will, then what does that mean for the other two non-trivial cases?
required=false,nullable=false with a default still makes sense. if the client leaves the field empty, that still sounds like the "i don't care" case, and the server should substitute the default value.
but does required=true,nullable=true with a default even make sense here? if the client says null, then the server should probably see that and be like "ok, client says and means no value"? maybe this is purely a "UX default" again: the client exposes API to say "explicitly send a null", or "explicitly send a value", and if the user chooses neither of those, then the client sends the default value?
but maybe thinking about this with "intent" in mind isn't the right approach; maybe this is all about wire format. maybe someone doesn't like leaving fields out, and so "whatever": null really does mean (to the server) "substitute the default if you see null".