Using the Contact API v3 I had a working implementation for uploading a photo to an existing contact.
Since a couple of weeks this fails with 404. The implementation has not been changed when the API servers started to sent back 404s and I don’t see any indication what exactly changed and would result now in the 404s.
I’m using HTTP PUT + the photo URL of the contact.
One interesting observation I made was that the contact’s self-URL changes which each request (the provided details are still always the same and correct).
Did anyone notice something similar ?
Edit: Link to issue: http://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3301&q=contact&colspec=API%20ID%20Type%20Status%20Priority%20Stars%20Opened%20Summary
-
tried different photo formats and sizes, different content types and even photos which had been uploaded previously (when it was still working). Nothing changed the behaviour of returning 404.
-
w.r.t to change contact ids: the contact ID changes between API invocations. I first thought it could be related to reopened connection( no keep-alive) that contact ids change. However what speaks against this being the cause of the issue is that first retrieving a contact and then editing a contact’s address is possible without any issues.
-
authentication does not seem to be problem as well – otherwise editing a contact’s address would not work as well.
PS: I’m using the JSON output format when retrieving the contact.
PS2: s/GET/PUT in step 3 ( I tried to change PUT to GET to see if it still returns 404… which it does).
PS3: am not using any client library but implement the protocol directly (which should not be relevant for the HTTP PUT on the photo link
After hours of investigation I found out that this is particular an issue using OAuth1. Using OAuth2 the exact same photo links which had been returned when requesting a specific contact record using OAuth1 work and return the photo data on HTTP GET. I expect HTTP PUT for photo links using OAuth2 to succeed as well.
Remains open if if there’s some kind of workaround for OAuth1.