API:Query

The action=query module allows for retrieving all sorts of data, and is loosely based on the now obsolete Query API. action=query is also used to retrieve tokens needed for editing and the like.

The query module has many submodules (called query modules), each with a different function. Query modules can be combined freely. There are three types of query modules:
 * Meta information about the wiki and the logged-in user
 * Listings of pages that match certain criteria
 * Properties of pages

Apart from query modules, action=query also has some features of its own.

Specifying titles
You can specify titles in the following ways:
 * Using the  parameter, e.g.
 * Using the  parameter, e.g.
 * Using the  parameter, e.g.
 * Most query modules will use the page the revision ID belongs to. Only prop=revisions actually uses the revision ID itself
 * Using a generator

Title normalization
Title normalization converts page titles to their canonical form. This means capitalizing the first character, replacing underscores with spaces, etc. Title normalization is done automatically, regardless of which query modules are used.

Missing and invalid titles
Titles that don't exist or are invalid still appear in the  section, but they have the   or   attribute set. In output formats that support numeric array keys (such as JSON and PHP serialized), missing and invalid titles will have unique, negative page IDs. Query modules will just ignore missing or invalid titles, as they can't do anything useful with them.

Resolving redirects
Redirects can be resolved automatically, so that the target of redirect is returned instead of the given title. The example below isn't really useful because it doesn't use any query modules, but shows how the  parameter works. Both normalization and redirection may take place. In case of double redirects, all redirects will be resolved, and in case of a circular redirect, there might not be a page in the 'pages' section (see also below).

Circular redirects
Assume Page1 &rarr; Page2 &rarr; Page3 &rarr; Page1 (circular redirect). Also, in this example a non-normalized name 'page1' is used.

Limits
To prevent server overloads, each query imposes a limit on how many items it can process. Anonymous and logged-in users have one limit, while bots and sysops have a considerably higher limit as they are trusted by the community. At present, each query simply lists the maximum request size it allows. For most query modules, this is 500 for anonymous and regular users, and 5000 for bots and sysops.
 * Drawbacks: Currently all limits are additive, so if the user requests allpages and backlinks, the user will get 500 of each. This is not very good, as the more items are compounded into one request, the heavier the load on the server will be. Instead, some sort of a weighted mechanism should be developed, where each request item has a certain "cost" associated with it, and each user is allocated a fixed allowance per request. The more information user requests, the less the limit becomes for that request. Unfortunately, that makes it very hard to figure out the maximum limits before executing the query, so might not be a workable solution.

Continuing queries
Very often, you will not get all the data you want in one request. To continue the a request, you can use the provided  value.

You can now use  to get the next ten categories.

Generators
With generators, you can use the output of a list instead of the  parameter. The output of the list must be a list of pages, whose titles are automatically used instead of the,   or   parameter. Other query modules will treat those pages as if they were provided by the user through the  parameter. Only one generator is allowed. List modules that don't list pages, can't be used as a generator. Some prop modules can also be used as a generator.

Parameters passed to a generator must be prefixed with a 'g'. For instance, when using generator=backlinks, use  instead of.

Generators and redirects
Here, we use prop=links as a generator. This query will get all the links from all the pages that are linked from Title. For this example, assume that Title has links to TitleA and TitleB. TitleB is a redirect to TitleC. TitleA links to TitleA1, TitleA2, TitleA3; and TitleC links to TitleC1 and TitleC2. Redirect are solved because the  parameter is set.

The query will execute the following steps:
 * 1) Resolve redirects for titles in the   parameter
 * 2) For all the titles in the   parameter, get the list of pages they link to
 * 3) Resolve redirects in that list
 * 4) Run the prop=links query on that list of titles

More generator examples

 * Show info about 4 pages starting at the letter "T"
 * http://en.wikipedia.org/w/api.php?action=query&generator=allpages&gaplimit=4&gapfrom=T&prop=info


 * Show content of first 2 non-redirect pages begining at "Re"
 * http://en.wikipedia.org/w/api.php?action=query&generator=allpages&gaplimit=2&gapfilterredir=nonredirects&gapfrom=Re&prop=revisions&rvprop=content