1.5. RESTCONF可扩展性

RESTCONF中内置了两种扩展机制：

  • 协议版本

  • 可选功能

本文档定义了RESTCONF协议的版本1。 如果定义了该协议的未来版本，那么该文档将指定如何识别新版本的RESTCONF。 预计将使用不同的RESTCONF根资源，该资源将使用不同的链接关系（请参阅第3.1节）。

服务器将通告其在主机元数据中支持的所有协议版本。

在这个例子中，服务器支持RESTCONF版本1和一个虚构的版本2。

客户端可能会发送以下内容：

  1. GET /.well-known/host-meta HTTP/1.1
  2. Host: example.com
  3. Accept: application/xrd+xml

服务器可能会如下回应：

  1. HTTP/1.1 200 OK
  2. Content-Type: application/xrd+xml
  3. Content-Length: nnn
  5. <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
  6.     <Link rel='restconf' href='/restconf'/>
  7.     <Link rel='restconf2' href='/restconf2'/>
  8. </XRD>

RESTCONF还支持服务器定义的可选功能列表，服务器使用第9.3节中定义的“ietf-restconf-monitoring”模块列出可选功能。 本文档定义了4.8节中的几个查询参数。 每个可选参数都有一个相应的能力URI，在9.1.1节中定义，如果受支持，由服务器通告。

“capability”叶列表可以识别任何类型的服务器扩展。 目前，这种扩展机制被用来识别支持的可选查询参数，但不限于此目的。 例如，第9.1.2节中定义的“defaults”URI指定了标识服务器默认处理行为的必需URI。

一个新的子资源类型可以用一个能力来标识，如果它是可选的实现的话。 强制协议功能和新资源类型需要RESTCONF协议的新版本。