Take the 2-minute tour ×
Stack Apps is a question and answer site for apps, scripts, and development with the Stack Exchange API. It's 100% free, no registration required.

http://code.google.com/p/simpleupdateprotocol/

The basic concept is that instead of polling individual API calls for changes, you make a single call to a 'SUP endpoint' which indicates any changes that have occurred in the last X seconds and you can make then appropriate API call to get the new data.

Use case:
I want to track updates to several questions at once.

The current options are to make API calls for each question (or bundle them together) and then check the timestamps and compare them to the last time I queried -- there is a lot of wasted bandwidth retrieving questions that didn't have any changes. To alleviate this, I could poll less frequently; but the end-user wants to be notified of the changes ASAP.

With SUP, I make one call to the SUP endpoint and I can determine which questions have changed and go retrieve them. Since the JSON returned is just a hashed key/value representing the changed data (and not the whole "Question structure"), I would anticipate a considerable bandwidth savings -- in addition to making it easier for developers to find out when data has been changed.

share|improve this question

1 Answer 1

up vote 0 down vote accepted

Provided you care about last_activity_date, your use case can be resolved with the following call:

http://api.stackoverflow.com/1.0/questions/{question id list}?sort=activity&min={last time you polled}

That will return only the questions that have changed (w.r.t. last_activity_date) since your last call.

If you only care that something has changed, you can add pagesize=0 to that and check total on the return.

I'm a little disinclined to implement anything like SUP, since the more general solution of just returning changed data (for some definition of changed) seems like a better fit (provided you can filter that data down to the interesting bits, which is a weak point of v1.0) for common use cases.

One request is better than two, after all.

share|improve this answer

You must log in to answer this question.

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