Requested feature overview description.
I propose that some form of XML's count attribute given to <posts> be added to the JSON API for post listing (/post/index.json). There might be other metadata that would be useful to include as well, but I feel that count is the most essential.

Why would it be useful?
Responses from queries to /post/index.xml include a count attribute in the top-level posts element. This is useful for performing calculating things such as how many pages of results were returned for a given 'limit' parameter.

There is the similar post_count field returned when querying /pool/show.json, allowing one to calculate how many pages need to be loaded to retrieve all the posts in the pool. Otherwise there would be no way to know if the pool is a single page or not.

However, this is not the case when querying /post/index.json - it lists all the responses, but gives no way to determine if further pages are available or not. The only way to determine that is to either detect when the number of returned posts is lower than 'limit', or to make one search request with the XML API just to get that single number.

What part(s) of the site page(s) are affected?
Posts, index
________________________________

It appears that @TonyLemur had, five years ago, stated they would attempt to address this. I don't know if it was addressed and its disappearance is a regression, or if this feature request has effectively been around for 5 years.

There isn't a good way to do this without breaking changes. The returned result set is an array, instead of an object, so there isn't a way to attach metadata to the result set except on every post in the result set.

Keep in mind that returned counts(regardless of where they are returned) are estimates and not exact values. Your approach of requesting results until the returned count is lower than the limit is the correct approach, and the only accurate one.

If you are requesting the full result set, please use before_id instead of using pages. It's faster, gives stable results even if new entries are added, and just makes your life easier.

KiraNoot said:
There isn't a good way to do this without breaking changes. The returned result set is an array, instead of an object, so there isn't a way to attach metadata to the result set except on every post in the result set.

Keep in mind that returned counts(regardless of where they are returned) are estimates and not exact values. Your approach of requesting results until the returned count is lower than the limit is the correct approach, and the only accurate one.

If you are requesting the full result set, please use before_id instead of using pages. It's faster, gives stable results even if new entries are added, and just makes your life easier.

What I have is a script that takes a number and a set of tags, to download that number of images resulting from that combination of tags. The number of results returned would only be used for indicating if there are fewer results than the number requested.

Regarding before_id, it was my belief that this would not work well if one of the given tags was order:(score|favcount). Am I incorrect in this assumption?

Tynach said:
Regarding before_id, it was my belief that this would not work well if one of the given tags was order:(score|favcount). Am I incorrect in this assumption?

The key part here is "the full result set". If you're requesting partial result sets where sorting is more important than getting the full list, then you have to use pages anyways, but you are strongly capped in the number you can obtain.

It's my general opinion that sorting during bulk requests is an anti-pattern.

For your specific scenario it doesn't sound like the information is actionable. If there are fewer posts it is unlikely to influence if the user chooses to download the results or not. It's just an informative "Hey, there aren't as many as you asked for." which can be displayed at the end when you have hit the end of the result set.