5

I have a feature request. I'm trying to pull the recent activity about a user from the API. So I'm parsing /users/{id}/timeline. But that only gives me meta-information about the activity. So then, for each result I need to re-call the /questions/{id}, /answers/{id} and /comments/{id} calls to get the actual data about what happened.

This is causing me to hit the rate-limit because instead of getting everything I need in 1 api call for the past 100 items, I need to hit the API 101 times...

So, I'm requesting a configuration parameter added to the timeline api call to allow the API to return the details of the referenced post for the following types:

  • askoranswered
  • comment

Basically, the containing information should be similar to calling the appropriate API (/questions/{id}, /answers/{id} and /comments/{id}) with both body=true and comments=true (for questions and answers).

I'd suggest: fullposts=true for the API parameter, and add it to the result under post: {}, the type for which can be determined by the post_type that's already in the result.

Improve this question
1
  • I'm not sure if you're using API v2 or not, but you do know that the /questions/{ids} endpoint (as well as /answers and /comments) in v2 will take multiple ids in one call. If you parse through the timeline, and then need more information, you can keep a list of all the question, answer, and comment ID's, and then join them together to make just one API call for each type. This is covered in the docs under Vectorized Requests (I may be misunderstanding what you're trying to do though, and if so, I apologize)
    – agent86
    Commented Feb 5, 2012 at 1:17

1 Answer 1

Reset to default
1

You shouldn't be making more than 4 requests in this case.

  • fetch a page of /users/{ids}/timeline
  • group the ids by type (question, answers, comments)
    • since the max pagesize fo users/{ids}/timeline is 100, we know there are < 100 of each id*
  • make 1 query each with the appropriate ids to /questions/{ids}, /answers/{ids}, and /comments/{ids}

This is the point behind vectorized requests (link is to the 2.0 docs, though I gather you're using v1.1; the concept is the same).

*No method takes more than 100 ids in an {ids} url parameter.

Improve this answer
3
  • I am using v2.0, but it winds up becoming screwy because I need to maintain ordering of the sets. I can definitely do it, the point was that it would be a whole lot easier (and more robust) if the data was returned in the original query, hence the feature request...
    – ircmaxell
    Commented Feb 6, 2012 at 19:30
  • It's declined, because it's possible to construct the data with other queries? Even though it's not trivial at all and requires a not-insignificant amount of logic to complete (whereas implementing it at the API level would be far easier)? Ultimately it's your product and decision, but I can't say that I see the logic in summarily declining it like that...
    – ircmaxell
    Commented Feb 8, 2012 at 16:18
  • @Kevin, about the point of vectorized requests: the point of filters is to choose what you want.
    – Jonathan.
    Commented Mar 7, 2012 at 19:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .