I'm trying to implement a client that fetches all liked posts from a specific user. Logic I'm using a loop that requests x posts from /v2/user/likes, increases the offset by x and makes another request, until there are no more posts (empty response). POST body is "offset=y&limit=x", y being increased by x every iteration and x being a fixed number of posts to fetch each request, 20 for example.
This worked fine for users with less than 1000 likes. For other users, when the loop reached an offset higher than 1000, API starts returning same response as offset=0. Is this an API limit?
On Thursday, March 29, 2012 3:05:31 PM UTC-5, Martin Spier wrote:
> I'm trying to implement a client that fetches all liked posts from a > specific user. Logic I'm using a loop that requests x posts from > /v2/user/likes, increases the offset by x and makes another request, until > there are no more posts (empty response). POST body is "offset=y&limit=x", > y being increased by x every iteration and x being a fixed number of posts > to fetch each request, 20 for example.
> This worked fine for users with less than 1000 likes. For other users, > when the loop reached an offset higher than 1000, API starts returning same > response as offset=0. Is this an API limit?
Any updates on this? I'm about to write a tool that allows to backup all of your likes but with this limit it's not very useful at the moment. Any chances to get this limit raised or maybe even removed entirely? What's the reason behind it anyway?
On Friday, March 30, 2012 4:12:38 PM UTC+2, felix bonkoski wrote:
> Yes 1000 "likes" seems to be an API limit. Larger offsets just start > loading likes from the beginning again.
> Why can't we fetch more than 1000? I don't know. Maybe Mr. Bunting has > something to add. :)
> felix
> On Thursday, March 29, 2012 3:05:31 PM UTC-5, Martin Spier wrote:
>> I'm trying to implement a client that fetches all liked posts from a >> specific user. Logic I'm using a loop that requests x posts from >> /v2/user/likes, increases the offset by x and makes another request, until >> there are no more posts (empty response). POST body is "offset=y&limit=x", >> y being increased by x every iteration and x being a fixed number of posts >> to fetch each request, 20 for example.
>> This worked fine for users with less than 1000 likes. For other users, >> when the loop reached an offset higher than 1000, API starts returning same >> response as offset=0. Is this an API limit?
On Thursday, March 29, 2012 at 4:05 PM, Martin Spier wrote:
> I'm trying to implement a client that fetches all liked posts from a specific user. Logic I'm using a loop that requests x posts from /v2/user/likes, increases the offset by x and makes another request, until there are no more posts (empty response). POST body is "offset=y&limit=x", y being increased by x every iteration and x being a fixed number of posts to fetch each request, 20 for example.
> This worked fine for users with less than 1000 likes. For other users, when the loop reached an offset higher than 1000, API starts returning same response as offset=0. Is this an API limit?
On Fri, Jun 22, 2012 at 5:58 AM, John Bunting <jo...@tumblr.com> wrote:
> Hey,
> Yep 1000 likes is the upper limit of what we expose on the API. So it's
> the last 1000 likes the user has liked.
> --
> John Bunting
> Simplicity is a prerequisite for reliability
> --Edsger W. Dijkstra
> On Thursday, March 29, 2012 at 4:05 PM, Martin Spier wrote:
> I'm trying to implement a client that fetches all liked posts from a
> specific user. Logic I'm using a loop that requests x posts from
> /v2/user/likes, increases the offset by x and makes another request, until
> there are no more posts (empty response). POST body is "offset=y&limit=x",
> y being increased by x every iteration and x being a fixed number of posts
> to fetch each request, 20 for example.
> This worked fine for users with less than 1000 likes. For other users,
> when the loop reached an offset higher than 1000, API starts returning same
> response as offset=0. Is this an API limit?
Where there are arbitrary limits in place on API calls like this, could we add a request for an offset_limit property in the meta object that is returned with the result? That way we could avoid giving duplicate data back to our users - and stop the need for us asking for this kind of detail.
Really, that information *should* all be in the API documentation. (*wink*
John)
Or ideally, there should be a JSON (or XML etc) interface to get all the
"documentation" information about the API. Google provides such things for
their public API's -- a call to get the "description" the API.
Felix
On Fri, Jun 22, 2012 at 6:59 AM, Steven Pears <steven.pe...@live.co.uk>wrote:
> Where there are arbitrary limits in place on API calls like this, could we
> add a request for an offset_limit property in the meta object that is
> returned with the result? That way we could avoid giving duplicate data
> back to our users - and stop the need for us asking for this kind of detail.
You guys are right. This should be in the documentation. I've been working on getting some auto generated documentation handy for use internally as well as externally.
The idea of the description route is quite interesting. I'll have to mull that one over, as well meta fields for things like rate limit and the such.
-- John Bunting
Simplicity is a prerequisite for reliability
--Edsger W. Dijkstra
On Friday, June 22, 2012 at 8:02 AM, felix bonkoski wrote:
> Really, that information *should* all be in the API documentation. (*wink* John)
> Or ideally, there should be a JSON (or XML etc) interface to get all the "documentation" information about the API. Google provides such things for their public API's -- a call to get the "description" the API.
> Felix
> On Fri, Jun 22, 2012 at 6:59 AM, Steven Pears <steven.pe...@live.co.uk (mailto:steven.pe...@live.co.uk)> wrote:
> > Where there are arbitrary limits in place on API calls like this, could we add a request for an offset_limit property in the meta object that is returned with the result? That way we could avoid giving duplicate data back to our users - and stop the need for us asking for this kind of detail.
On Fri, Jun 22, 2012 at 8:55 AM, John Bunting <jo...@tumblr.com> wrote:
> You guys are right. This should be in the documentation. I've been working
> on getting some auto generated documentation handy for use internally as
> well as externally.
> The idea of the description route is quite interesting. I'll have to mull
> that one over, as well meta fields for things like rate limit and the such.
> --
> John Bunting
> Simplicity is a prerequisite for reliability
> --Edsger W. Dijkstra
> On Friday, June 22, 2012 at 8:02 AM, felix bonkoski wrote:
> Really, that information *should* all be in the API documentation.
> (*wink* John)
> Or ideally, there should be a JSON (or XML etc) interface to get all the
> "documentation" information about the API. Google provides such things for
> their public API's -- a call to get the "description" the API.
> Felix
> On Fri, Jun 22, 2012 at 6:59 AM, Steven Pears <steven.pe...@live.co.uk>wrote:
> Where there are arbitrary limits in place on API calls like this, could we
> add a request for an offset_limit property in the meta object that is
> returned with the result? That way we could avoid giving duplicate data
> back to our users - and stop the need for us asking for this kind of detail.
I do want to take the time to thank you all for your suggestions and information. I read every email that comes across the list and even if sometimes I don't respond right away (or at all because I get a lot of email >.<), I appreciate the input.
Any other community improving ideas are welcome and you guys can always drop me a line on this email or the list.
-- John Bunting
Simplicity is a prerequisite for reliability
--Edsger W. Dijkstra
On Friday, June 22, 2012 at 10:22 AM, felix bonkoski wrote:
> The auto-generated documentation would probably feed quite nicely into an "API Description" interface as well.
> Felix
> On Fri, Jun 22, 2012 at 8:55 AM, John Bunting <jo...@tumblr.com (mailto:jo...@tumblr.com)> wrote:
> > You guys are right. This should be in the documentation. I've been working on getting some auto generated documentation handy for use internally as well as externally.
> > The idea of the description route is quite interesting. I'll have to mull that one over, as well meta fields for things like rate limit and the such.
> > -- > > John Bunting
> > Simplicity is a prerequisite for reliability
> > --Edsger W. Dijkstra
> > On Friday, June 22, 2012 at 8:02 AM, felix bonkoski wrote:
> > > Really, that information *should* all be in the API documentation. (*wink* John)
> > > Or ideally, there should be a JSON (or XML etc) interface to get all the "documentation" information about the API. Google provides such things for their public API's -- a call to get the "description" the API.
> > > Felix
> > > On Fri, Jun 22, 2012 at 6:59 AM, Steven Pears <steven.pe...@live.co.uk (mailto:steven.pe...@live.co.uk)> wrote:
> > > > Where there are arbitrary limits in place on API calls like this, could we add a request for an offset_limit property in the meta object that is returned with the result? That way we could avoid giving duplicate data back to our users - and stop the need for us asking for this kind of detail.
On Friday, June 22, 2012 10:03:09 AM UTC-5, John Bunting wrote:
> I do want to take the time to thank you all for your suggestions and > information. I read every email that comes across the list and even if > sometimes I don't respond right away (or at all because I get a lot of > email >.<), I appreciate the input.
> Any other community improving ideas are welcome and you guys can always > drop me a line on this email or the list.
> -- > John Bunting
> Simplicity is a prerequisite for reliability > --Edsger W. Dijkstra
> On Friday, June 22, 2012 at 10:22 AM, felix bonkoski wrote:
> The auto-generated documentation would probably feed quite nicely into an > "API Description" interface as well.
> Felix
> On Fri, Jun 22, 2012 at 8:55 AM, John Bunting <jo...@tumblr.com> wrote:
> You guys are right. This should be in the documentation. I've been working > on getting some auto generated documentation handy for use internally as > well as externally.
> The idea of the description route is quite interesting. I'll have to mull > that one over, as well meta fields for things like rate limit and the such.
> -- > John Bunting
> Simplicity is a prerequisite for reliability > --Edsger W. Dijkstra
> On Friday, June 22, 2012 at 8:02 AM, felix bonkoski wrote:
> Really, that information *should* all be in the API documentation. > (*wink* John)
> Or ideally, there should be a JSON (or XML etc) interface to get all the > "documentation" information about the API. Google provides such things for > their public API's -- a call to get the "description" the API.
> Felix
> On Fri, Jun 22, 2012 at 6:59 AM, Steven Pears <steven.pe...@live.co.uk>wrote:
> Where there are arbitrary limits in place on API calls like this, could we > add a request for an offset_limit property in the meta object that is > returned with the result? That way we could avoid giving duplicate data > back to our users - and stop the need for us asking for this kind of detail.
Yes. +1 for John. You deserve a raise :P I'd drop a note on
http://www.davidslog.com/ask -- but somehow I doubt Mr. Karp reads those
hahaha.
But hey, since you're in such a good mood this afternoon... maybe I'll
just put a tiny wish list here for you...
1. Ability to get the Post Author information on posts from Group Blogs
(Now supported in Tumblr Themes, although it wasn't for a long time. Not
sure when they added it, but it must have been fairly recently. In the
Theme Code, you've got {PostAuthorName} {PostAuthorTitle} {PostAuthorURL}
etc. That sure would be nice to get with the Blog post info through the
API)
I've got a few clients who could use this feature. Right now I just
have to use hacky workarounds.
2. Pwetty pweez let us fetch more than 50 blog posts at once again? I know
it was a *bug* when i used to be able to fetch 250 posts at a time.... but
it was just soooo much faster that way.
I know you're not Santa Claus, though, so.... Anyway, thanks for all your
hard work. Everyone here in this group appreciates you very much!
On Fri, Jun 22, 2012 at 10:03 AM, John Bunting <jo...@tumblr.com> wrote:
> I do want to take the time to thank you all for your suggestions and
> information. I read every email that comes across the list and even if
> sometimes I don't respond right away (or at all because I get a lot of
> email >.<), I appreciate the input.
> Any other community improving ideas are welcome and you guys can always
> drop me a line on this email or the list.
> --
> John Bunting
> Simplicity is a prerequisite for reliability
> --Edsger W. Dijkstra
> On Friday, June 22, 2012 at 10:22 AM, felix bonkoski wrote:
> The auto-generated documentation would probably feed quite nicely into an
> "API Description" interface as well.
> Felix
> On Fri, Jun 22, 2012 at 8:55 AM, John Bunting <jo...@tumblr.com> wrote:
> You guys are right. This should be in the documentation. I've been working
> on getting some auto generated documentation handy for use internally as
> well as externally.
> The idea of the description route is quite interesting. I'll have to mull
> that one over, as well meta fields for things like rate limit and the such.
> --
> John Bunting
> Simplicity is a prerequisite for reliability
> --Edsger W. Dijkstra
> On Friday, June 22, 2012 at 8:02 AM, felix bonkoski wrote:
> Really, that information *should* all be in the API documentation.
> (*wink* John)
> Or ideally, there should be a JSON (or XML etc) interface to get all the
> "documentation" information about the API. Google provides such things for
> their public API's -- a call to get the "description" the API.
> Felix
> On Fri, Jun 22, 2012 at 6:59 AM, Steven Pears <steven.pe...@live.co.uk>wrote:
> Where there are arbitrary limits in place on API calls like this, could
> we add a request for an offset_limit property in the meta object that is
> returned with the result? That way we could avoid giving duplicate data
> back to our users - and stop the need for us asking for this kind of detail.
