-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Partial post/patch support #3846
Comments
Thanks for reaching out. |
Thanks. I read about that, but I suspect it's not going to work in our case for two reasons:
|
Thanks for the additional information.
And it doesn't account for readonly properties, init only properties, etc... So rather than picking a design that would lock a lot of scenarios out, we picked one that was a bit broader, even though it might come at a cost of not being specific enough in some cases. As the standard evolves, we'll review those decisions. While the backing store was primarily designed for a fetch before update scenario, I believe it could be used to cover the one you've shared. var modelInstance = new MyModel();
modelInstance.PropA = null;
var result = KiotaJsonSerializer.SerializeAsString(modelInstance); Do you get |
Thank you for the additional information.
Yes, and @darrelmiller, architect for kiota and long time core member of the OpenAPI technical steering committee is working on OpenAPI v4 (with others) with those considerations in mind.
We understand it's a bit inconvenient at the moment, but adding a switch would go against the pillar principal of keeping kiota simple. NRT is a feature very specific to dotnet (arguably Go and TypeScript could have a similar behavior), and we don't want to add switches that are specific to languages. This is because ultimately it complexifies the CLI experience, makes the maintenance matrix a whole lot more difficult, etc... Our strategy over time is to take advantage of the more precise capabilities of OpenAPI v4. When we get there, we might also be able to drop support for netstandard2.0/net framework, which means we'll be able to modernize the dotnet we're generating a great deal. |
I fail to understand why it would be appropriate for a server to express these. Read-only and init-only are client-side and language-specific concerns that don't describe the expected shape of exchanged data. Can you elaborate on that?
Fair enough. In that case, I suppose it makes sense for a C# client to infer "optional non-nullable properties are expressed as nullable", although this is opinionated. And that optional nullable properties are inferred as nullable. And that required nullable properties are inferred as nullable. What I think is incorrect is that required non-nullable properties are inferred as nullable. That's like going back to the time before NRT was introduced: you'll never know whether something is functionally required. I'd say it's up to servers to decide how models (components) are shared. In our JSON:API implementation, we chose to define distinct models for GET, POST and PATCH payloads. An alternate design would be to reuse models, but then we'd define every property as optional because of partial POST/PATCH: any omitted attributes are considered unchanged (PATCH) or use a server-defined default (POST), which would result in Kiota generating nullable properties, which works well. While there a pros and cons to both component designs, it's ultimately the server making the decision and the client should just follow along to its best abilities. A client-generator that contradicts the expressed "required non-nullable" sounds like a bug to me. Would you like me to open a separate issue for that? |
Not at the moment, because again, kiota has this opiniated choice (ultimately wrong, I agree) to account for shortcomings of the standard and mis-use from a majority of the services out there. Yes ideally all services should deeply think about client experience, and if they expect a property to be required in a POST scenario, but optional in a GET scenario, use two different schemas. But the vast majority will use a single one today for simplicity, which leads to locking people out of some scenarios if you follow the spec and the description to the letter. Our hope is that with the v4 which has more specific mechanism, it'd enable people to describe things with re-usable schemas, but apply contextual "constraints", getting the best of both worlds. (and in that context, kiota'd have to project multiple types for the "same" schema)
There are additional scenarios that I failed to mention like idempotency for instance.
|
Well, it's not a hard blocker, so I can live with it, for now at least, though I expect questions and/or bug reports from our users regarding this if we adopt Kiota. Yet I sense some frustration in your response, wondering why. So I searched existing issues for "nullable" and noticed this question came up several times before, where you basically explained the same things as here and closed the issue. It may help to keep an open issue around so people won't keep asking about this. Even if low priority, or a strategic decision to postpone fixing, it would enable others to upvote so the team can reconsider this design choice in the future. Likewise, I saw initial pushback on implementing NRT support in a Kiota issue, which happened eventually. We're not on a tight deadline, but OpenAPI 4 sounds like years away before largely adopted in the ecosystem. Swashbuckle doesn't even support 3.1 because they're still waiting on Microsoft OpenAPI.NET to implement it. As far as I'm aware, no OpenAPI 3.1 server libraries exist for .NET today. These new v4 features seem to address higher-level architectural patterns, that may not compose well with existing standards, which makes universal adoption take a very long time, if at all. For example, JSON:API addresses these concerns differently and its authors are unlikely to break with earlier versions of their spec, just because of new OpenAPI features. They consider OpenAPI and similar schema languages an implementation detail; it was discussed years ago without reaching consensus. |
Please go ahead and open an issue dedicated to that, I'll add it to the v3 milestone and we'll take it from there.
The initial pushback was due to the lack of support for this feature in netstandard2.0/netfx. We eventually figured out a solution with conditional compilation, arguably it's a bit of a noisy solution.
My team is ultimately also responsible for this library. Progress has been slow because we took this opportunity to:
|
Great to hear this is getting attention. I've created #3911 to track |
I'm looking for a way to mark properties in request bodies to be explicitly included in the payload, even when their values are
null
. This is required for JSON:API compliance, specifically:Omitting a property in the request body means leaving its stored value unchanged, whereas sending it with value
null
instructs to update the stored value. This poses a problem for C# clients. There's no way to distinguish whether a property isnull
because it was never set, or that it was intentionally set tonull
because it needs to be cleared.To address this, we use the following with NSwag:
where
WithPartialAttributeSerialization()
is a method provided by our NSwag extension library that hooks into the underlying Newtonsoft serializer by registering a customContractResolver
that overridesNullValueHandling
/DefaultValueHandling
at runtime. Theusing
ensures the registration forfirstName
is cleared afterwards, so the API client can be reused.I'm looking for a way to provide a similar feature using Kiota. Any pointers on where to hook in would be greatly appreciated.
The text was updated successfully, but these errors were encountered: