6

Update: This was completed as of API version 2.1.

When querying any API method which returns answers (/users/ids/answers, /answers/ids, etc.) the result does not include the tag information for the related question.

The API does not support filtering answers by tag, but querying for a user's answers is a relatively inexpensive operation for all but the most prolific users. These can subsequently be filtered/sorted without need for additional API calls if the tag data were included for each answer result.

I feel this would add great value to the data without needing to pull all the questions.

Improve this question
0

1 Answer 1

Reset to default
1

Hmmm... this is an interesting problem.

Just going off of usage statistics, nearly everybody is grabbing answers as part of /questions/{id} or /questions. This strongly suggests that what use of */answers there is, is largely independent of corresponding question (if I had to guess, I'd say its generally user analytics of some sort).

However, one of the points of */answers is to allow for an optimization in which you skip the corresponding */questions call. Obviously this doesn't work if you want to keep tags in sync.

This is very much "on the margin," ultimately. If better response filtering schemes pan out in a subsequent API version, this will probably be done; if not it probably won't.

In other words, I'd say returning tags on an answer is a waste of bandwidth in the common case but there's a sufficiently valid use case such that an optional return has merit. I'm putting this on the "re-evaluate at a later date" list.

Improve this answer
3
  • Consider that I am interactively scrutinizing a particular user and I want to examine their answers. The only vector for user specific answers is /users/id/answers which contains a question stub giving me the context I need to determine if I am interested in pulling the question.. with the exception of the tags. While analytics would be a valid use case, I have a real world case of interactive browsing and the inclusion of tags in the stub would economize the case of browsing a user's answers.
    – Sky Sanders
    Commented Sep 23, 2010 at 17:04
  • 1
    So, in this case, which will become more common i am sure, the inclusion of a few more bytes in the question stub compared to servicing additional request on /questions would result in significantly less bandwith overall.
    – Sky Sanders
    Commented Sep 23, 2010 at 17:06
  • I'd like to make a stronger case for including tags for each answer. Anybody attempting to do user analytics (as you've correctly divined) then has to perform N vectorized calls to /questions/ids, which is bounded by URL length, not number of IDs—an incredibly brittle solution that wastes a ton of API calls and bandwidth just to get a short list of tags. IOW, providing tags (even as an optional return) is a valuable bit of information about an answer, and punches above its weight in terms of bandwidth & API request savings. Please reconsider and add this feature!
    – Idan Gazit
    Commented Nov 15, 2011 at 8:33

You must log in to answer this question.

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