API:Query/ms

The  module allows you to fetch information about a wiki and the data stored in it, such as the wikitext of a particular page, the links and categories of a set of pages, or the token you need to.

Query modules
The query module has three types of submodules (also called query modules):


 * about the wiki and the logged-in user.
 * of pages, including page revisions and content.
 * of pages that match certain criteria.

Example 1: Specifying pages
Unlike meta and list query modules, all property query modules work on a set of pages that can be specified in one of the following ways:

Most query modules will convert revision ID to the corresponding page ID. Only actually uses the revision ID itself.
 * By name using the  parameter, e.g..
 * By page ID using the  parameter, e.g..
 * By revision ID using the  parameter, e.g..
 * Using a generator.

Example 2: Title normalization
Title normalization converts page titles to their canonical form.

This means capitalizing the first character, replacing underscores with spaces, and changing namespace to the localized form defined for that wiki.

Example 3: Missing and invalid titles
Titles that don't exist or are invalid will have a  or   attribute set in the response.

In output formats that support numeric array keys, missing and invalid titles will have negative page IDs.

In some cases, a title can be viewed by a user but cannot be accessed by the API, such as pages that mirror content from another wiki. These titles will have a  attribute set in the response.

Example 4: Continuing queries
When all the data is not returned in the response of a query, there will be a  attribute to indicate that there is more data.

Response
To get further data, add its values to the original request:

Example 5: Batchcomplete
The API returns a  element to indicate that all data for the current batch of items has been returned.

In the response of the sample query below,  has been included to indicate that all the data for each of the three images has been returned.

The next continuation will begin returning data for the next set of 3 images.

Example 6: Generators
Use generators if you want to get data about a set of pages.

For example, to get data about pages in a certain category, instead of querying  and then querying again with   set to all the returned pages, combine the two API calls into one by using.

When using a list module as a generator, you don't need to specify the pages.

However, for a property module, you should specify the pages which the generator will work on.

For example, to load all pages that are linked to from the main page, use.

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

The sample query below gets links and categories for the first three pages in the main namespace starting with "Ba".

Continuing queries
Very often you will not get all the data you want in one API query. When that happens the API result indicates there is more data.

Because there are more data matching the query, the API result includes a  element. If you want further data, you would add its values (in the example,  and  ) to the original request to get the next set of results. You continue to do this until an API result does not have a  element, indicating there are no more data matching the query.

Here is Python code showing how to iterate over query results (using the python requests lib). Note you should not manipulate or depend on any specifics of the values returned inside the  element, as they may change.

batchcomplete
When you make an API request using a generator together with properties, the API result may signal to continue because there are more properties to retrieve for the pages so far, or because there are more pages from the generator, or both. From version 1.25 onwards, the API returns a  element to indicate that all data for the current "batch" of pages has been returned. This can be useful to avoid building a combined result set for thousands of pages when using a generator together with prop modules that may themselves need continuation.

Backwards compatibility of continue
From MediaWiki 1.21 to 1.25, it was required to specify  (i.e. with an empty string as the value) in the initial request to get continuation data in the format described above. Without doing that, API results would indicate there is additional data by returning a  element, explained in Raw query continue. Prior to 1.21, that raw continuation was the only option.

If your application needs to use the raw continuation in MediaWiki 1.26 or later, you must specify  to request it.

Parameter history

 * v1.21: Introduced
 * v1.24: Introduced (note raw continuation was the default behavior until v1.26)

Additional notes

 * Specifying titles through  or   is limited to 50 titles per query, or 500 for those with the   right.
 * Use multiple query modules together to get what you need in one request, e.g..
 * Generators always pass page titles to the query module. Unlike lists (which may include additional data by default), generators should not output any information themselves, unless when explicitly requested via the generator module's query parameters.

Resolving redirects
Redirects can be resolved automatically, so that the target of a redirect is returned instead of the given title. When present, they will always contain  and   attributes and may contain a   attribute for those redirects that point to specific sections.

Both normalization and redirection may take place. In the case of multiple 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). Redirect resolution cannot be used in combination with the  parameter or with a generator generating revids; doing that will produce a warning and will not resolve redirects for the specified revids.

The examples below show how the  parameter works.