API:Main page/zh


 * 这是一个关于"action"API的概览. 在右侧的菜单栏中可查看更详细的子主题和其他API

MediaWiki action API是一个通过HTTP来提供对wiki功能、数据与元数据便携访问的Web服务，一般通过这一URL来实现. 客户端通过指定 来请求相应的动作，一般用 来获取信息. 这曾被 称为 MediaWiki API，但现在还有其他可以连接到MediaWiki的web API，例如RESTBase和维基数据查询服务.

介绍
如果您是在寻找“内部 API”或者“PHP API”，请查看扩展界面，它允许PHP开发人员向维基百科增加新的功能.

MediaWiki action API可以用于监视维基百科的新增条目或者制作机器人来自动维护. 它提供了直接、高级别的对包含在MediaWiki数据库中的数据的访问. 客户端程序可以通过制作HTTP请求给web服务，自动登录wiki、获取数据并发布更改. 支持的客户端包括机器人程序、基于web的轻量级JavaScript（例如导航popup和LiveRC）、最终用户应用程序（例如Vandal Fighter）和其他web网站（[//tools.wmflabs.org 工具实验室]的实用工具）.

新安装的MediaWiki中，此web服务默认启用，但管理员可以把它禁用.

對於MediaWiki有另外兩個朝外的接口：


 * Special:Export頁面提供了批量导出維基上的內容為XML这一功能. 閱讀以獲取更多信息.
 * 本標準的基於Web的界面（你很可能使用的是現在瀏覽這個頁面）. 閱讀參數的信息，使用基於Web的界面.

简单例子
这个URL让英文维基百科的web服务API向您传送首页的内容：

用任意编程语言向这个URL发送一个HTTP GET请求（或直接在浏览器中打开这个链接），您便可得到一个JSON文档，其中包含“Main Page”页面中当前的wiki代码. 这就是一个能运作的web服务API. 把格式更改为 将会返回一个“装饰过的”HTML 结果，使之更适合于调试.

我们来分解这个URL，以展示它如何工作.

接入点
這是''端點'. 這就像MediaWiki的Web服務API的主頁. 這個URL是英文維基百科的API的基礎URL，就像 網址是其網站的基本URL.

如果您写一个使用英文维基百科的程序，每一个您需要构造的URL都以这个基础URL开头. 如果您在其他MediaWiki系统上操作，您需要找到它的接入点，并相应地使用那个地址. 所有Wikimedia的wiki的接入点都符合这个模式：

从开始，我们在末端使用RSD：寻找任意页面的HTML源代码中的 ，并提取 URL；这是包含额外信息的实际链接. 例如，本維基是：

否則，沒有安全的方式找到任何維基端點. If you're lucky, either the full path to index.php will not be hidden under strange rewrite rules so that you'll only have to take the "edit" (or history) link and replace index.php (etc.) with api.php, or you'll be able to use the default script path (like ).

现在让我们接着了解URL中查询字符串的参数.

格式
这是向API请求返回JSON格式的数据. 可能你也会想去尝试 来得到一个易于调试的HTML格式的结果. API同时也支持其它的输出格式 例如XML和原生PHP，但是我们计划移除一些不常用的格式(T95715)，我们不建议您去使用它们.

操作
MediaWiki web service API接口拥有很多的操作和扩展接口；动态生成的API帮助文档拥有wiki上所有可用操作的描述. 在这种情况下，我们使用“query”操作来获取信息. “query”操作是API最重要的操作之一，并且具有大量的技术文档. 下面是一个简单例子和它的解释.

特定行为的参数
示例URL的剩余部分包含由“query”操作使用的参数. Here, we're telling the web service API that we want information about the Wiki page called "Main Page". （%20是百分号编码空格. ） If you need to query multiple pages, put them all in one request to optimize network and server resources:. 参见查询文档以获取详情.

You can request many kinds of information, or properties, about a page. This parameter tells the web service API that we want information about a particular revision of the page. Since we're not specifying any revision information, the API will give us information about the latest revision &mdash; the main page of Wikipedia as it stands right now.

Finally, this parameter tells the web service API that we want the content of the latest revision of the page. If we passed in  instead, we'd get the latest page content and the name of the user who made the most recent revision.

再次注意，这只是一个示例. Queries are explained in more detail here, and the API reference lists all the possible actions, all the possible values for, and so on.



入门
Before you start using the MediaWiki web service API, be sure to read these documents:


 * The FAQ.
 * The page about input and output formats
 * The page about errors and warnings
 * Any policies that apply to the wiki you want to access, such as Wikimedia Foundation wikis' terms of use, trademark policy. These terms apply to you when you access or edit using the API, just as they do when you use your web browser.

Beyond that point, what you need to read depends on what you want to do. The right-hand menu links to detailed, task-specific documentation, and some more general guidelines are given below.

验证您的客户端
当你发送HTTP请求到MediaWiki网络服务API时，请确保指定了能够指明你的客户端的 头. 不要使用客户端库中默认的 ，而应自定义一个能指明你的脚本或服务的头，并提供联系方式(例如电子邮件).

一个User-Agent字符串示例如下： MyCoolTool/1.1 (https://example.org/MyCoolTool/; MyCoolTool@example.org) BasedOnSuperLib/1.4

在Wikimedia中，如果你不提供 头，或者提供了一个空的或通用的，你的请求将会以HTTP 403错误回应(参考:$mua-policy). 其他的MediaWiki站点可能有类似的策略.

If you are calling the API from browser-based JavaScript, you won't be able to influence the  header: the browser will use its own. To work around this, use the  header:

In PHP, you can identify your user-agent with code such as this:

或如果您使用cURL：

登录
Your client will probably need to log in to MediaWiki, possibly via its own user account. See the login manual page for details.

API使用礼仪
另请阅读API:礼仪

If your requests obtain data that can be cached for a while, you should take steps to cache it, so you don't request the same data over and over again. More information about rate-limiting, concurrency, and general API etiquette can be found at API:Etiquette. Some clients may be able to cache data themselves, but for others (particularly JavaScript clients), this is not possible.

Per the HTTP specification, POST requests cannot be cached. Therefore, whenever you're reading data from the web service API, you should use GET requests, not POST.

Also note that a request cannot be served from cache unless the URL is exactly the same. If you make a request for, and cache the result, then a request for   will not go through the cache — even though MediaWiki returns the same data!

You should take care to normalize the URLs you send to the MediaWiki web service, so that slightly different user input won't cause you to waste time on unnecessary HTTP requests. You can normalize a list of page titles by removing duplicates and sorting the titles alphabetically. Similar techniques will work for other kinds of data.

实用链接
The menu bar on the right side of this page links to more detailed, task-specific documentation. Here are some links having to do with the API as a whole:


 * 在所有维基媒体wiki上都可用的API沙盒，这使交互式尝试不同操作变得容易.
 * [//en.wikipedia.org/w/api.php The API reference] contains automatically-generated descriptions of all actions and parameters.
 * Hook into Wikipedia information using PHP and the MediaWiki API (IBM developerWorks article, 17 May 2011)
 * Hook into Wikipedia using Java and the MediaWiki API (6 April 2012)
 * The API tutorial leads you through hands-on exercises and includes a training video.
 * 用于通知和问题的邮件列表：API邮件列表
 * Low-traffic mailing list for announcements only (all posts to this list are posted to mediawiki-api as well): mediawiki-api-announce
 * 在MediaWiki-API Phabricator项目中浏览并汇报API错误（当汇报新错误时，不要忘记添加MediaWiki-API至项目一栏中）
 * — 当前的MediaWiki数据架构
 * — 当前的MediaWiki数据架构

存档链接

 * 2006年API讨论