引言

本规范描述了RESTful API建模语言（RAML）。RAML是用于定义RESTful应用程序编程接口（API）的人机交互语言。RAML旨在通过提供API提供者和API消费者可以用作相互契约的格式来改进API的规范。例如，便于为客户端和服务器实现提供用户文档和源代码存根。这样的设置简化和增强了使用RESTful API的可互操作应用程序的定义和开发。

RAML引入了资源类型和特征的创新概念，用于表征和重用资源模式和相关方法。使用资源类型和特性可最大限度地减少RESTful API设计中的重复，并提高API内部和跨API的一致性。

本文件组织如下：

• 基本信息. 如何描述API的核心方面，例如其名称，标题，位置（或URI）和默认值，以及如何包括API的支持文档。
• 数据类型. 通过包含JSON和XML模式的流线型类型系统来建模API数据。
• 资源. 如何在任何URI模板中指定API资源和嵌套资源，以及URI参数。
• 方法. 如何指定API资源及其请求标头，查询参数和请求正文的方法。
• 响应. API响应的规范，包括状态代码，媒体类型，响应头和响应正文。
• 资源类型和特征. 可选地使用RAML资源类型和特征来表征资源。
• 安全. 在RAML中指定API安全方案。
• 注释. 通过定义强类型的注释并在整个规范中应用它来扩展RAML规范。
• 包含，库，覆盖和扩展. API定义如何由外部化定义文档组成，将这些定义的集合打包到库中，在RAML文档上分离和覆盖元数据层，以及扩展具有附加功能的API规范。

RAML 1.0中的新增功能和不同之处

• 数据类型：一种统一，简化和强大的方式来模拟数据出现在API中的任何地方。
  • 统一覆盖主体，URI参数，标题和查询参数，并且不需要单独的formParameters构造
  • 支持封装XML模式和JSON模式，甚至引用子模式，但在许多情况下，只是消除模式
  • 通过基于YAML的方式，简化了与JSON模式或XML模式的编码
• 示例：多个示例，可在YAML中表达，并且可注释，因此可以注入语义
• 注释：一个经过测试的，强类型的可扩展性机制
• 库：改进的模块化，用于广泛重用API工件
• 覆盖和扩展：通过分隔文件增加可扩展性
• 改进的安全计划：
  • 更广泛的OAuth支持
  • 支持传递（基于密钥）安全方案
• 一些更小的更改一致性和表达性

标记语言

本规范使用YAML 1.2作为其基本格式。YAML是一种人类可读的数据格式，与本规范的设计目标一致。与YAML中一样，所有节点（如键，值和标记）都区分大小写。

RAML API定义是符合YAML 1.2标准的文档，以符合要求的YAML注释行开头，指示RAML版本，如下所示：

#%RAML 1.0
title: My API

RAML API定义文档的第一行必须以文本开头， #%RAML后跟一个空格，后跟文本1.0，并且在当前行尾前没有其他的东西。RAML片段文档类似地开始于RAML版本注释和片段标识符，但不是自己的RAML API定义文档。

媒体类型application / raml yaml及其关联的文件扩展名.raml应用于指定包含RAML API定义，RAML片段和包含RAML标记的文件的文件。RAML还能够包括其他媒体类型的文档，诸如“application/schema+json”和“application/yaml”。

为了方便RAML文档的自动处理，除了核心YAML 1.2规范之外，RAML还强加了以下限制和要求：

• RAML文件的第一行由指定RAML版本的YAML注释组成。因此，RAML处理器不能完全忽略所有YAML注释。
• RAML文档中某些级别的某些属性的顺序很重要。因此，期望处理器保持这种排序。

文档的根

RAML文档的根部分描述了有关API的基本信息，例如其标题和版本。根部分还定义在RAML文档中其他位置使用的资产，例如类型和特性。

RAML记录的API定义中的节点可以按任何顺序出现。处理器必须在定义树的同一节点内保持相同类型的节点的顺序。这样的节点的示例是出现在资源树的相同级别的资源，给定资源的方法，给定方法的参数和给定类型中相同级别的节点。处理器还必须保持数组中项的顺序。

此示例显示了GitHub v3公共API的RAML API定义的一小部分。

#%RAML 1.0
title: GitHub API
version: v3
baseUri: https://api.github.com
mediaType:  application/json
securitySchemes:
  oauth_2_0: !include securitySchemes/oauth_2_0.raml
types:
  Gist:  !include types/gist.raml
  Gists: !include types/gists.raml
resourceTypes:
  collection: !include types/collection.raml
traits:
securedBy: [ oauth_2_0 ]
/search:
  /code:
    type: collection
    get:

下表列出了RAML文档根目录下的可能节点：

“schemas”和“types”节点是相互排斥和同义的：处理器不能允许在API定义的根级指定两者。我们建议使用“types”节点而不是“schemas”，因为模式别名已过时，可能会在将来的RAML版本中删除。

用户文档

The OPTIONAL documentation node includes a variety of documents that serve as user guides and reference documentation for the API. Such documents can clarify how the API works or provide technical and business context.
可选documentation节点包括各种文档，用作API的用户指南和参考文档。这些文档可以阐明API的工作原理或提供技术和业务上下文。

The value of the documentation node is a sequence of one or more documents. Each document is a map that MUST have exactly two key-value pairs described in following table:
文档节点的值是一个或多个文档的序列。每个文档都是一个映射，必须有下表中描述的两个键值对：

This example shows an API definition having two user documents.
此示例显示具有两个用户文档的API定义。

#%RAML 1.0
title: ZEncoder API
baseUri: https://app.zencoder.com/api
documentation:
 - title: Home
   content: |
     Welcome to the _Zencoder API_ Documentation. The _Zencoder API_
     allows you to connect your application to our encoding service
     and encode videos without going through the web  interface. You
     may also benefit from one of our
     [integration libraries](https://app.zencoder.com/docs/faq/basics/libraries)
     for different languages.
 - title: Legal
   content: !include docs/legal.markdown

基本URI和基本URI参数

可选baseUri节点将URI指定为整个API的标识符，并且可以用于指定提供API的URL（其服务端点），并且其形成其每个资源的URL的基础。baseUri节点的值是必须符合URI规范 RFC2396 或模板URI.的字符串。

如果baseUri值是 模板URI，则以下保留的基本URI参数可用。

在baseUri中出现的任何其他URI模板变量可以在API定义根目录下的baseUriParameters节点中显式地描述。baseUriParameters节点与资源节点上的uriParameters节点具有相同的结构和语义，除了它指定基本URI中的参数，而不是资源的相对URI。

如果baseUri值是模板URI，则以下保留的基本URI参数可用。

#%RAML 1.0
title: Salesforce Chatter REST API
version: v28.0
baseUri: https://na1.salesforce.com/services/data/{version}/chatter

以下示例声明了一个显式基本URI参数。

#%RAML 1.0
title: Amazon S3 REST API
version: 1
baseUri: https://{bucketName}.s3.amazonaws.com
baseUriParameters:
  bucketName:
    description: The name of the bucket

当基本URI以一个或多个斜杠（/）结尾时，在使用该基本URI的资源的绝对路径中省略那些尾部斜线。例如，在以下代码段中，资源的绝对路径为http://api.test.com/common/users和http://api.test.com/common/users/groups。

baseUri: http://api.test.com/common/
/users:
  /groups:

在下面，更多复杂的例子，在多个地方连续的斜线，基本URI中只有尾部斜线被折叠，导致这些资源的绝对路径：//api.test.com//common/，//api.test.com/common/users/，//api.test.com//common//users//groups//。

baseUri: //api.test.com//common//
/:
  /users/:
    /groups//:

协议

可选协议节点指定API支持的协议。如果协议节点未被明确指定，则使用包括在baseUri节点中的一个或多个协议;如果协议节点被明确指定，则节点规范覆盖包括在baseUri节点中的任何协议。协议节点必须是非空的字符串数组，值为HTTP和/或HTTPS，并且不区分大小写。

以下是同时接受HTTP和HTTPS请求的API端点示例。

#%RAML 1.0
title: Salesforce Chatter REST API
version: v28.0
protocols: [ HTTP, HTTPS ]
baseUri: https://na1.salesforce.com/services/data/{version}/chatter

默认媒体类型

指定可选mediaType节点可设置具有正文的响应和请求的默认媒体类型。您不需要在每个主体定义中指定媒体类型。

mediaType节点的值必须是媒体类型字符串序列或单个媒体类型字符串。媒体类型适用于具有正文，预期响应和使用相同媒体类型字符串序列的示例的请求。每个值都需要符合 RFC6838中的媒体类型规范。

此示例显示用于接受并返回JSON格式的正文的API的RAML片段。如果此API规范的其余部分未明确指定另一种媒体类型，则此API接受并返回仅JSON格式的主体。

#%RAML 1.0
title: New API
mediaType: application/json

此示例显示用于接受和返回JSON或XML格式的主体的API的RAML片段。

#%RAML 1.0
title: New API
mediaType: [ application/json, application/xml ]

为API请求或响应的主体显式定义mediaType节点将覆盖默认媒体类型，如以下示例所示。资源/list返回表示为JSON或XML的Person []正文。资源/send通过显式地定义一个application/json节点来覆盖默认的媒体类型。因此，资源/send仅返回JSON格式的主体。

#%RAML 1.0
title: New API
mediaType: [ application/json, application/xml ]
types:
  Person:
  Another:
/list:
  get:
    responses:
      200:
        body: Person[]
/send:
  post:
    body:
      application/json:
        type: Another

默认安全

指定可选securedBy节点为API中的每个资源的每个方法设置默认安全方案并保护。节点的值是安全方案名称的数组。有关详细信息，包括如何通过继承解决多个安全方案的应用程序，请参阅应用安全方案 一节。

以下示例显示了允许通过OAuth 2.0安全方案或OAuth 1.1安全方案进行访问的API。

#%RAML 1.0
title: Dropbox API
version: 1
baseUri: https://api.dropbox.com/{version}
securedBy: [ oauth_2_0, oauth_1_0 ]
securitySchemes:
  oauth_2_0: !include securitySchemes/oauth_2_0.raml
  oauth_1_0: !include securitySchemes/oauth_1_0.raml