Perhaps I can offer an opinion on cacheability of the API. Please don't downvote before reading through.

###Caching is hard Caching and cache invalidation is hard. Often, if not always, you need to intimately know the data to be able to cache it effectively.

In order to enable a generic Etag caching ability the server will need to execute the request and then get a hash for it to compare with the requested hash. So, from server's point of view, this kind of caching is pointless.

Take a look, for example, at this request (which is the heaviest I could think of - requesting 100 answers with body):

http://api.stackoverflow.com/0.9/questions/9033/answers?pageSize=100&body=true

Answers request http://img641.imageshack.us/img641/6236/answerrequest.png

It takes the server nearly twice the transfer time to process the request. So, a trivial implementation of Etag caching would be at most 50% efficient.

###Validation using time

You could possibly have an even more trivial caching that simply caches by URL and, for example, if the URL matches exactly something the server did before than it would either serve cached data or reply with Not Modified. However, I would think that cache hits on exact API URLs would be pretty rare.

###Expiration-based caching

Again, without actually getting the data from the DB, the best the server can do is give you an estimate of how long it thinks the data will be valid for. This is the kind of thing that an app/wrapper can actually do for itself. E.g. do not request the answers for a particular question more than once a minute. Which brings me to the next point:

###Wouldn't it be easier for the API to provide data "freshness" intervals for different kinds of requests as an API call?

This way the app has the option of requesting data more frequently than the server thinks it's valid for and giving the app the ability to cache with possibly better freshness confidence than the app would guess.

Regardless,

###Caching at the application level trumps all

Let me give you a half example, half plug. Stack Tagz does two levels of caching.

One is completed timeseries - this is the graph that you see. I consider that questions don't really get retagged all that often, so once it calculates a timeseries, it's persisted to the DB. Requesting a graph for Jon Skeet takes about 400 requests (which would be smaller if the vectorized requests are fixed, hint hint). It'd be crazy to make those requests every time someone wants to look at his graph, especially considering it won't look any different next week.

Another is caching of individual questions. There is significant overlap if multiple people answer the same question, no good reason to request it again. Even if a question is retagged/deleted, it's OK, there are plenty of other data points for it to be statistically significant.

So, I guess what I am trying to say, is that different apps have different tolerances for the data freshness, and hence can improve on the most pessimistic guarantee that the API can provide. Individual app makers should really think about caching, not delegate it all to the API.

Perhaps I can offer an opinion on cacheability of the API. Please don't downvote before reading through.

Caching is hard

Caching and cache invalidation is hard. Often, if not always, you need to intimately know the data to be able to cache it effectively.

In order to enable a generic Etag caching ability the server will need to execute the request and then get a hash for it to compare with the requested hash. So, from server's point of view, this kind of caching is pointless.

Take a look, for example, at this request (which is the heaviest I could think of - requesting 100 answers with body):

http://api.stackoverflow.com/0.9/questions/9033/answers?pageSize=100&body=true

Answers request http://img641.imageshack.us/img641/6236/answerrequest.png

It takes the server nearly twice the transfer time to process the request. So, a trivial implementation of Etag caching would be at most 50% efficient.

Validation using time

You could possibly have an even more trivial caching that simply caches by URL and, for example, if the URL matches exactly something the server did before than it would either serve cached data or reply with Not Modified. However, I would think that cache hits on exact API URLs would be pretty rare.

Expiration-based caching

Again, without actually getting the data from the DB, the best the server can do is give you an estimate of how long it thinks the data will be valid for. This is the kind of thing that an app/wrapper can actually do for itself. E.g. do not request the answers for a particular question more than once a minute. Which brings me to the next point:

Wouldn't it be easier for the API to provide data "freshness" intervals for different kinds of requests as an API call?

This way the app has the option of requesting data more frequently than the server thinks it's valid for and giving the app the ability to cache with possibly better freshness confidence than the app would guess.

Regardless,

Caching at the application level trumps all

Let me give you a half example, half plug. Stack Tagz does two levels of caching.

One is completed timeseries - this is the graph that you see. I consider that questions don't really get retagged all that often, so once it calculates a timeseries, it's persisted to the DB. Requesting a graph for Jon Skeet takes about 400 requests (which would be smaller if the vectorized requests are fixed, hint hint). It'd be crazy to make those requests every time someone wants to look at his graph, especially considering it won't look any different next week.

Another is caching of individual questions. There is significant overlap if multiple people answer the same question, no good reason to request it again. Even if a question is retagged/deleted, it's OK, there are plenty of other data points for it to be statistically significant.

So, I guess what I am trying to say, is that different apps have different tolerances for the data freshness, and hence can improve on the most pessimistic guarantee that the API can provide. Individual app makers should really think about caching, not delegate it all to the API.