According to the documentation, the following call should return a single person:
https://graph.microsoft.com/v1.0/me/people/33b43a5b-87d6-41ec-91f8-a2610048105f
Currently, instead of returning a person entity, it is returning an HTTP 500 response.
{
"error": {
"code": "ErrorInternalServerError",
"message": "An internal server error occurred. The operation failed.",
"innerError": {
"request-id": "ec913bd4-0ea6-4c60-a0ee-9c56c9fec14e",
"date": "2018-05-09T13:59:18"
}
}
}
Yep, I see this too. I'm not really sure what the scenario would be for requesting a person by ID in this manner though. What I've seen with the id values that come back from GET /me/people:
personType/subclass == ImplicitContact, there is no "thing" in the server that corresponds to the entry, it's just a derived object based on your collaborations. Not sure what id maps to here.personType/subclass == OrganizationUser, the id is actually the user's id from AAD, so you can get the corresponding user by GET /users/{id}. This probably also holds true for other types that map directly to AAD objects, like groups.That isn't exhaustive by any means, and is just based on my own observations. To be honest the People API stuff needs a lot of love in our docs. We don't list the possible values of personType/subclass, things like that. Let me sync with the People API PM and come back.
I got confirmation from the People API PM that this was never intended to work. This is just an error in the documentation. The person_get.md files should be removed.
Most helpful comment
Yep, I see this too. I'm not really sure what the scenario would be for requesting a person by ID in this manner though. What I've seen with the
idvalues that come back fromGET /me/people:personType/subclass==ImplicitContact, there is no "thing" in the server that corresponds to the entry, it's just a derived object based on your collaborations. Not sure whatidmaps to here.personType/subclass==OrganizationUser, theidis actually the user'sidfrom AAD, so you can get the corresponding user byGET /users/{id}. This probably also holds true for other types that map directly to AAD objects, like groups.That isn't exhaustive by any means, and is just based on my own observations. To be honest the People API stuff needs a lot of love in our docs. We don't list the possible values of
personType/subclass, things like that. Let me sync with the People API PM and come back.