msgraph-sdk-dotnet
msgraph-sdk-dotnet copied to clipboard
Skip generation for the /me endpoints
As part of the Go effort to decrease the size and optimize the performance of the pre-package service library, one of the solutions was to map internally all the /me endpoints to target the users/{user-id}. /me and /users/{id} are effectively identical from a metadata perspective. This presents an opportunity to reduce build time while minimally impacting the experience for users.
We still wanna keep the experience of having .Me as part of the fluent API, so while we are removing the /me path we still need to be able to do something as the following:
client.Me.GetAsync()
TODO:
- [ ] in graph core, add a UrlReplaceOption request option. It needs to implement the interface and provide accessors for Enabled (default true) as well as "ReplacementPairs" (map[string]string), default [/users/me-token-to-replace, /me]
- [ ] in graph core add a UrlReplaceHandler that implements the middleware handler, replaces the tokens in the URLs, and traces its activity with the telemetry.
- [ ] in graph core, add this new handler as part of the defaults
- [ ] in code generator, update the go weekly generation steps to exclude /me (exclude paths, /me and /me/**, or something similar)
- [ ] trigger a code generation from beta
- [ ] in that newly generated PR, update the dependency to core
- [ ] in that newly generated PR, cherry pick the first commit
- [ ] update the snippets generation to map inline types and namespacing for /me to /users
NOTE: the list above was copied from the Go repo. Apply as needed.
As part of the /me work, we also need to make sure to address the issue mentioned here where batch requests using /me segment are generating incorrect URLs.
With the propose changes, does it also mean that we will get ride of some of the duplicated namespaces. E.g. .Me.Calendar and .Me.Calendars[id] will produce from what I can tell the same Types, but they come from different namespaces (which also don't inherit from each other) resulting in that all the code (e.g. setting headers/query parameters etc) needs to be duplicated if you want to support both. It would be way more conveniënt if they would both return the same types (in the same namespaces) so the rest of the configuration of the requests can be unified.