Closed pdestefanis closed 4 years ago
@pdestefanis According to issue #6 it is by design....pfft....Come on Microsoft. Time to get with the times and fix this please.
@microsoftgraph The community and actual end users are having issues and yet we get no traction on actual issues as they are shrugged of as designed code. The time in what it takes to respond to issues on this repository is also shocking to be honest. We are being advised to use Microsoft Graph in favour of other older and working solutions, yet here we are, struggling with issues that are not being addressed.
Sorry for the frustration here and the slow response. There's a number of issues at play here, so it would be helpful if you could help me understand your concern. I certainly don't want to shrug things off, but at the same time I want to be honest and straightforward with you :)
I'm taking @pdestefanis original comment to be in regards to the REST API itself (which is what returns the 404). I believe this is what James' meant when he said this is by design (and I'm assuming he confirmed that with engineering). 'manager' isn't a property on the user, it's a navigation property that's directly addressable. 404 to indicate there's nothing at that address seems reasonable. Let me check with the devs on this to be sure.
It's possible I'm misunderstanding the feedback though. If the concern is that the Graph SDK should not be throwing an exception for this request, the best place to provide that feedback would be in the SDK repo: https://github.com/microsoftgraph/msgraph-sdk-dotnet
If the feedback was more that this sample should handle the exception differently, that's something we can address in this repository.
Wanted to give an update: I spoke with the PM for this area of the Graph, and on the topic of the service returning 404, that's something that is currently being discussed internally. The API probably should return 204 No Content, and that might be something we change in future versions. Changing it in the v1 endpoint for Graph might constitute a breaking change so it's less likely the behavior would change there.
The call should return null, but instead it is returning a 404. This cannot be "by design"