Pomax
Sort many photosets with 'flickr.photosets.orderSets' fails (URI too long)
When I tried to change the order of my photosets using your package I ran into a problem, because I had too many photosets and therefore the URI of request was too long.
Try to use POST requests for such methods. If it's any help take a look at the same issue in a python flickrapi implementation: https://github.com/sybrenstuvel/flickrapi/issues/74
What do you mean with "too many photosets"? The photoset responses should be paged, like any other response, so the number of sets should not matter, you just need to run through all pages (I have 50+ sets myself and have not run into issues there yet)
I think you missunderstood me - I'm not talking about retrieving the photosets, but ordering them using the endpoint flickr.photosets.orderSets. I have 100-200 photosets and when I try to order them, the URI is too long, because all the ids go in the query parameter.
looking at https://www.flickr.com/services/api/flickr.photosets.orderSets.html, this should already be a POST (not a GET) so that's more a bug than a feature request I guess. Looking at the compiled code it seems there is no mark to tell the library that it must use POST rather than GET so that'll need to be added into the api builder/parser.
It may be so. I looked inside your code and I saw no way to make this a POST request by default. I tried to fix it myself but I ran into problems with the signing procedure.
On Sat, Jan 13, 2018, 18:57 Mike Kamermans [email protected] wrote:
looking at https://www.flickr.com/services/api/flickr.photosets.orderSets.html, this should already be a POST (not a GET) so that's more a bug than a feature request I guess.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Pomax/node-flickrapi/issues/108#issuecomment-357453695, or mute the thread https://github.com/notifications/unsubscribe-auth/AFes9gvJTgip-s_XpvBlk744_WUClgdhks5tKO4igaJpZM4ROIhe .
yeah there are no provisions for POST atm, the API parser will need an update to discover that certain methods require POST rather than GET, with the query function updated to check for the method and falling through to either a getQuery, with the current code, or a postQuery, which would form a simple signed URL with a post payload representing the required arguments for the call to return a proper result.