As an aside, nearly always use limit=max, and also look at the apihighlimits right too

In the case of the user interaction tool, "Make Your Own API" is probably the right solution, although I wouldn't be opposed to making the MediaWiki API pagination more flexible. Generally though, in cases where you are sifting through huge amounts of data, you'll want to query against a database directly rather than sucking all the data over via API and then querying it.

In T180080#3746340, @Reedy wrote:

also look at the apihighlimits right too

These are anonymous cross-domain requests directly from the web browser.

In T180080#3746399, @kaldari wrote:

In the case of the user interaction tool, "Make Your Own API" is probably the right solution, although I wouldn't be opposed to making the MediaWiki API pagination more flexible. Generally though, in cases where you are sifting through huge amounts of data, you'll want to query against a database directly rather than sucking all the data over via API and then querying it.

Completely agree. It just seems like kind of an anti-pattern, but yeah there will always be use cases that are outside the use cases the API supports.

In T180080#3746418, @dbarratt wrote:

Completely agree. It just seems like kind of an anti-pattern, but yeah there will always be use cases that are outside the use cases the API supports.

If you are in Toolforge (it sounds like you are or you would just be writing the Action API module you need), the Wiki Replicas allow you to query the revision tables directly. This kind of analytics/data mining work is a core use case for those servers existing.

In T180080#3748252, @Anomie wrote:

If you need to know if User A edited a page at some point in time, try https://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=PAGE&rvuser=Kaldari&rvlimit=1. That should be reasonably efficient for logged-in users since it should use the page_user_timestamp index.

As I mentioned before:

In T180080#3746418, @dbarratt wrote:

These are anonymous cross-domain requests directly from the web browser.

I tried an article I know Kaldari hasn't edited, and it shows up in the results:
https://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=Frontier%20City&rvuser=Kaldari&rvlimit=1
so that doesn't really work for our use-case, but thanks for the suggestion anyways!

In T180080#3748329, @dbarratt wrote:

I tried an article I know Kaldari hasn't edited, and it shows up in the results:
https://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=Frontier%20City&rvuser=Kaldari&rvlimit=1
so that doesn't really work for our use-case, but thanks for the suggestion anyways!

I think you're mis-interpreting the results. Compare https://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=User:Legoktm&rvuser=Legoktm&rvlimit=1& and your query. The fact that there's no revisions listed in your Kaldari query means that he's never edited the article.

In T180080#3748420, @Legoktm wrote:

I think you're mis-interpreting the results. Compare https://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=User:Legoktm&rvuser=Legoktm&rvlimit=1& and your query. The fact that there's no revisions listed in your Kaldari query means that he's never edited the article.

Oh! I see. Thank you! That is very helpful.

In T180080#3748329, @dbarratt wrote:

In T180080#3748252, @Anomie wrote:

If you need to know if User A edited a page at some point in time, try https://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=PAGE&rvuser=Kaldari&rvlimit=1. That should be reasonably efficient for logged-in users since it should use the page_user_timestamp index.

As I mentioned before:

In T180080#3746418, @dbarratt wrote:

These are anonymous cross-domain requests directly from the web browser.

Besides the misinterpretation Lego pointed out, my bad word choice in saying "logged-in" rather than "registered" may have been confusing. I was trying to say that it won't work efficiently if you supply a value for rvuser that doesn't correspond to a registered user, e.g. "127.0.0.1" or "SomeUserNameThatIsn'tRegistered". It doesn't matter whether the query is being made while logged-in or not.

The reason for that is because with a registered rvuser it can use the page_user_timestamp index to directly look for edits to the page by the user ID, while for an IP or non-registered name it has to use either page_timestamp (all edits to the page) then filter by user or usertext_timestamp (all edits by username) then filter by page.

In T180080#3748559, @Anomie wrote:

Besides the misinterpretation Lego pointed out, my bad word choice in saying "logged-in" rather than "registered" may have been confusing. I was trying to say that it won't work efficiently if you supply a value for rvuser that doesn't correspond to a registered user, e.g. "127.0.0.1" or "SomeUserNameThatIsn'tRegistered". It doesn't matter whether the query is being made while logged-in or not.

The reason for that is because with a registered rvuser it can use the page_user_timestamp index to directly look for edits to the page by the user ID, while for an IP or non-registered name it has to use either page_timestamp (all edits to the page) then filter by user or usertext_timestamp (all edits by username) then filter by page.

Ah! Thank you for clarifying.

I created T180156: Interaction Timeline should make simpler requests to determine if pages have been edited to updated our tool given your suggestions.

Also, I found that there are pros and cons to different pagination strategies:
http://blog.vermorel.com/journal/2015/5/8/nearly-all-web-apis-get-paging-wrong.html

The token based pagination that we have now is the safest but obviously has other limitations.