当您的客户与未知网站交谈时,您需要了解该网站的能力以及该网站的配置方式。 这有几个步骤,这取决于你需要发现什么。
##发现API
连接到网站的第一步是找出网站是否启用了API。 通常,您将使用用户输入的URL,因此您访问的网站可能是任何东西。 发现步骤允许您验证API是否可用,以及如何访问它。
##链接头
处理发现的首选方法是向所提供的地址发送HEAD请求。 REST API会自动将Link标头添加到所有前端页面,如下所示:
链接:<http://example.com/wp-json/>; rel =“https://api.w.org/”>
该URL指向API的根路径(/),然后将其用于进一步的发现步骤。
对于没有启用“漂亮的永久链接”的网站,/ wp-json /不会被WordPress自动处理。 这意味着将使用正常/默认的WordPress固定链接。 这些标题看起来更像这样:
链接:<http://example.com/?rest_route=/>; rel =“https://api.w.org/”
客户应牢记这种变化,并确保两条路线能够无缝地处理。
此自动发现可以应用于WordPress安装服务的任何URL,因此不需要添加用户输入的预处理。 由于这是HEAD请求,所以请求应该安全地盲目发送到服务器,而不用担心会产生副作用。
##元素
对于具有HTML解析器或在浏览器中运行的客户端,通过“<link>”元素,前端页面的<head>中包含了Link标题的等价物:
```
<link rel='https://api.w.org/' href='http://example.com/wp-json/' />
```
In-browser Javascript can access this via the DOM:
```
// jQuery method
var $link = jQuery( 'link[rel="https://api.w.org/"]' );
var api_root = $link.attr( 'href' );
// Native method
var links = document.getElementsByTagName( 'link' );
var link = Array.prototype.filter.call( links, function ( item ) {
return ( item.rel === 'https://api.w.org/' );
} );
var api_root = link[0].href;
```
对于浏览器中的客户端,或客户端无法访问HTTP标头,这可能是更有用的发现API的方式。 这与Atom / RSS feed发现类似,因此也可以自动为此目的使用现有的代码
改为代替。
## RSD(真正简单发现)
对于支持XML-RPC发现的客户端,RSD方法可能更适用。 这是一种通常用于XML-RPC的基于XML的发现格式。 RSD有两个步骤。 第一步是找到RSD端点,以“<link>”元素的形式提供:
```
<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://example.com/xmlrpc.php?rsd" />
```
第二步是获取RSD文档并解析可用的端点。 这涉及在如下文档中使用XML解析器:
```
<?xml version="1.0" encoding="utf-8"?>
<rsd version="1.0" xmlns="http://archipelago.phrasewise.com/rsd">
<service>
<engineName>WordPress</engineName>
<engineLink>https://wordpress.org/</engineLink>
<homePageLink>http://example.com/</homePageLink>
<apis>
<api name="WordPress" blogID="1" preferred="true" apiLink="http://example.com/xmlrpc.php" />
<!-- ... -->
<api name="WP-API" blogID="1" preferred="false" apiLink="http://example.com/wp-json/" />
</apis>
</service>
</rsd>
```
REST API始终具有名称属性,其值等于WP-API。
RSD是自动发现的最不喜欢的方法,有几个原因。 基于RSD的发现的第一步涉及解析HTML以首先找到RSD文档本身,这相当于<link>元素自动发现。 然后,它需要另一个步骤来解析RSD文档,这需要一个完整的XML解析器。
在可能的情况下,由于复杂性,我们建议避免基于RSD的发现,但如果现有的XML-RPC客户端已经启用了RSD解析器,则可能更喜欢使用此方法。 对于希望使用REST API作为逐步增强代码库的XML-RPC客户机,这避免了需要支持不同形式的发现。
##认证发现
发现也可用于通过API可用的身份验证方法。 API根的响应是描述API的对象,其中包含一个验证密钥:
```
{
"name": "Example WordPress Site",
"description": "YOLO",
"routes": { ... },
"authentication": {
"oauth1": {
"request": "http://example.com/oauth/request",
"authorize": "http://example.com/oauth/authorize",
"access": "http://example.com/oauth/access",
"version": "0.1"
}
}
}
```
认证值是认证方法ID与认证选项的映射(关联数组)。 这里提供的选项特定于身份验证方法本身。 有关特定身份验证方法的选项,请参阅身份验证文档。
##扩展发现
一旦您发现了API,下一步就是检查API支持的内容。 API的索引公开了命名空间项,其中包含支持的API的扩展名。
对于使用版本4.4到4.6的WordPress网站,只有基本API基础架构可用,而不是具有端点的完整API。 这也包括oEmbed端点:
```
{
"name": "Example WordPress Site",
"namespaces": [
"oembed/1.0/"
]
}
```
具有完整API(即安装了WordPress 4.7+或安装了REST API插件)的网站也将在命名空间中使用wp / v2项目:
```
{
"name": "Example WordPress Site",
"namespaces": [
"wp/v2",
"oembed/1.0/"
]
}
```
在尝试使用任何核心端点之前,您应该确保通过检查wp / v2支持来检查API是否受支持。 WordPress 4.4启用所有站点的API基础架构,但不包括wp / v2下的核心端点。 核心终端在WordPress 4.7中添加。
这种相同的机制可用于检测支持REST API的任何插件的支持。 例如,拿一个注册以下路由的插件:
```
<?php
register_rest_route( 'testplugin/v1', '/testroute', array( /* ... */ ) );
```
This would add the testplugin/v1 namespace to the index:
```
{
"name": "Example WordPress Site",
"namespaces": [
"wp/v2",
"oembed/1.0/",
"testplugin/v1"
]
}
```
- 简介
- 主题开发
- WordPress许可证
- 什么是主题
- 开发环境
- 主题开发示例
- 主题基础
- 模板文件
- 主样式表(style.css)
- 文章类型
- 规划主题文件
- 模板层级
- 模板标签
- 循环
- 主题函数
- 连接主题文件和目录
- 使用CSS和JavaScript
- 条件标签
- 类别,标签和自定义分类
- 模板文件
- 内容模板文件
- 页面模板文件
- 附件模板文件
- 自定义内容类型
- 部分和其他模板文件
- 评论模板
- 分类模板
- 404页面
- 主题功能
- 核心支持的功能
- 管理菜单
- 自定义Headers
- 自定义Logo
- 文章格式
- 置顶文章
- Sidebars
- Widgets
- 导航菜单
- 分页
- 媒体
- Audio
- Images
- Galleries
- Video
- 精选图片和缩略图
- 国际化
- 本地化
- 辅助功能
- 主题选项 – 自定义API
- 定制对象
- 改进用户体验的工具
- 定制JavaScript API
- JavaScript / Underscore.js渲染的自定义控件
- 高级用法
- 主题安全
- 数据消毒/逃避
- 数据验证
- 使用随机数
- 常见漏洞
- 高级主题
- 子主题
- UI最佳实践
- JavaScript最佳做法
- 主题单元测试
- 验证你的主题
- Plugin API Hooks
- 发布你的主题
- 所需的主题文件
- 测试
- 主题评论指南
- 写文档
- 提交你的主题到WordPress.org
- 参考文献
- 模板标签列表
- 条件标签列表
- 编码标准
- HTML编码标准
- CSS编码标准
- JavaScript编码标准
- PHP编码标准
- 插件开发
- 插件开发简介
- 什么是插件
- 插件基础
- 头部要求
- 包括软件许可证
- 启用 / 停用 Hooks
- 卸载方法
- 最佳做法
- 插件安全
- 检查用户功能
- 数据验证
- 保护输入
- 保护输出
- 随机数
- Hooks
- Actions
- Filters
- 自定义Hooks
- 高级主题
- 管理菜单
- 顶级菜单
- 子菜单
- 短代码
- 基本短码
- 封闭短码
- 带参数的短代码
- TinyMCE增强型短码
- 设置
- 设置API
- 使用设置API
- 选项API
- 自定义设置页面
- 元数据
- 管理帖子元数据
- 自定义元数据
- 渲染元数据
- 自定义文章类型
- 注册自定义文章类型
- 使用自定义文章类型
- 分类
- 使用自定义分类
- 在WP 4.2+中使用“split术语”
- 用户
- 创建和管理用户
- 使用用户元数据
- 角色和功能
- HTTP API
- JavaScript
- jQuery
- Ajax
- 服务器端PHP和入队
- Heartbeat API
- 概要
- 计划任务
- 了解WP-Cron计划
- 安排WP-Cron 事件
- 将WP-Cron挂接到系统任务计划程序中
- WP-Cron简单测试
- 国际化
- 本地化
- 如何国际化您的插件
- 国际化安全
- WordPress.org
- 详细插件指南
- 规划您的插件
- 如何使用Subversion
- 插件开发者常见问题
- 开发工具
- Debug Bar 和附加组件
- 辅助插件
- REST API手册
- 资源
- 文章
- 文章修订
- 文章类型
- 文章状态
- 类别
- 标签
- 页面
- 评论
- 分类
- 媒体
- 用户
- 设置
- 使用REST API
- 全局参数
- 分页
- 链接和嵌入
- 发现
- 认证
- 经常问的问题
- 骨干JavaScript客户端
- 客户端库
- 扩展REST API
- 添加自定义端点
- 自定义内容类型
- 修改回应
- 模式
- 词汇表
- 路由和端点
- 控制器类