I'm making the following request against the Microsoft Live API:
GET https://apis.live.net/v5.0/me/picture?access_token=ACCESS_TOKEN
The result, unlike any other request to that API, is a redirect to a physical image location, which causes the actual image object to be returned instead of a typical JSON response that would include the path to that image.
I could dig into the the response object and try to get the Content-Location header or something to get the URL I'm looking for, but that feels very brittle and diverges from the way I'm handling every other API response.
I also know that the API URL itself, based on this behavior, can act as the image URL, but 1) I'm using a client that constructs that URL behind the scenes and 2) I don't want to persist the access token in something like a profile picture column.
The Interactive Live SDK actually shows a JSON object as the return for a REST request:
{
"location": "https://cid-0000000000000000.users.storage.live.com/users/0x0000000000000000/myprofile/expressionprofile/profilephoto:UserTileStatic"
}
That is the kind of response I want, and since the interactive SDK can show it, there's got to be some way to request that JSON be returned. I've tried setting redirect=false in the query string (necessary for Facebook, which does something similar) and setting the Accept request header to application/json. Neither had any effect.
This is not truly an answer to my question, so I'd still be interested any responses along the lines of my original question. However, I have found a workaround of sorts.
The URL
https://apis.live.net/v5.0/{user_id}/picturewill return the appropriate photo photo without requiring an access token. Therefore, all you need is the the user's id to construct this URL, and that can be obtained via:Which will return something akin to:
The
idmember there, is what you need for the URL. It's not ideal, because I have to sort of do two steps, and hope Microsoft doesn't change the way the profile picture for a specific user is retrieved or suddenly starts requiring an access token for that too. It's better than nothing, though, I suppose.