Skip to content
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

Add a default application/xml serialization library #342

Open
andrueastman opened this issue Aug 23, 2024 · 1 comment
Open

Add a default application/xml serialization library #342

andrueastman opened this issue Aug 23, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@andrueastman
Copy link
Member

Looks like some endpoints on Graph support application/xml content type now. e.g https://learn.microsoft.com/en-us/graph/api/trustframeworkpolicy-get?view=graph-rest-beta

To provide a better customer experience, we should add an xml serialization library that is registered with other serializers too.

Related to microsoftgraph/msgraph-beta-sdk-dotnet#883

@github-project-automation github-project-automation bot moved this to Needs Triage 🔍 in Kiota Aug 23, 2024
@andrueastman andrueastman added the enhancement New feature or request label Aug 23, 2024
@andrueastman andrueastman moved this from Needs Triage 🔍 to Proposed 💡 in Kiota Aug 23, 2024
@baywet
Copy link
Member

baywet commented Aug 23, 2024

$value is a "binary payload" by nature in odata conventions. Meaning it's not schematized. So even if we implemented a parsing/serialization provide for XML, the description would still not contain a schema for this operation. And kiota would still generate a Task or equivalent.

We could get around that by adding post processing to the OAS description, or something in XOD + implementation in Yoko, but that's probably a lot of work end to end for a single scenario at this point.

My recommendation here is that we leave this on ice until we get overwhelming customer demand for it.

Of course the other scenarios being:

  • Graph can technically return xml instead of JSON for most structured endpoints if you ask nicely. But I'm not sure why anybody choose that when it's going to result in heavier payloads and when they already have a client using JSON.
  • 3rd party APIs might be XML only. But so far nobody has requested support for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Proposed 💡
Development

No branches or pull requests

2 participants