legacy-api-documentation
legacy-api-documentation copied to clipboard
Inconsistent data coming from /photos[feature='user'] endpoint
Hi there, I have the feeling that the data coming from the /photos endpoint, passing feature=user, user_id=$my_user_id (the same which performs the OAuth) is inconsistent and eventually converges only after some hours.
Example: I've have currently 4 photos in my photostream (they were 5 but I removed one of them through the API). If I log in in the 500px website I see 4 pics.
First weird thing:
In the 500px.com/manage web interface, the status of the left bar is (see screenshot):
LIBRARY
All Photos: 4
Public profile: 4
SETS
AlbumName: 5
Which sounds to me incorrect according to your data model, as a set cannot possibly have more photos than I have in the library (or am I missing something here?). However, if I click on the album I then see only 4 photos, and the counter for AlbumName fixes and goes back to 4 as soon as I click.
From an API viewpoint, the /photos endpoint keeps listing 5 photos ['69384865', '69385195', '69385093', '69385111', '69385095']. Four of them are correct, but one (69384865) does not exists, and if I try to perform API queries on that (e.g., GET photos/:id) it fails with a 4xx error.
Is this behavior expected? It sounds like a serious consistency-related bug.
This is my experience with 500PX API when I was coding for my own version of Android SDK. If you move a photo to set, it will not be removed from your photo. I think it is designed to be like this. On May 4, 2014 5:55 PM, "Primiano Tucci" [email protected] wrote:
Hi there, I have the feeling that the data coming from the /photos endpoint, passing feature=user, user_id=$my_user_id (the same which performs the OAuth) is inconsistent and eventually converges only after some hours.
Example: I've have currently 4 photos in my photostream (they were 5 but I removed one of them through the API). If I log in in the 500px website I see 4 pics.
First weird thing: In the 500px.com/manage web interface, the status of the left bar is (see screenshot): LIBRARY All Photos: 4 Public profile: 4 SETS AlbumName: 5 [image: screen shot 2014-05-04 at 10 49 34 pm]https://cloud.githubusercontent.com/assets/7137473/2874100/090f76c8-d3d6-11e3-84a4-1be2e0f17c66.png
Which sounds to me incorrect according to your data model, as a set cannot possibly have more photos than I have in the library (or am I missing something here?). However, if I click on the album I then see only 4 photos, and the counter for AlbumName fixes and goes back to 4 as soon as I click.
From an API viewpoint, the /photos endpoint keeps listing 5 photos ['69384865', '69385195', '69385093', '69385111', '69385095']. Four of them are correct, but one (69384865) does not exists, and if I try to perform API queries on that (e.g., GET photos/:id) it fails with a 4xx error.
Is this behavior expected. It sounds like a serious consistency-related bug.
— Reply to this email directly or view it on GitHubhttps://github.com/500px/api-documentation/issues/77 .
I don't see how this information is anyhow related with the issue I am reporting, which to be honest sounds much more like a bug. I don't see how Android is anyhow related here. I don't see the sense of the sentence "If you move a photo ... it will not removed from your photo".
Of course what you (are probably trying to) explain is the data model of 500px which, similarly to Flickr, treats photos as shared resources, which can belong to 0, 1 ore any number of sets/albums/collections (however do you want to spell them).
This issue being reported here is different. The issue here is that the "list all my photos" API is listing photos which do not exist anymore (i.e. for which a photos/:id GET request fails with a 4xx error) for long periods of time.