1.4. 与NETCONF共存

RESTCONF可以在支持NETCONF协议的设备上实现。

下图显示了如果RESTCONF服务器与NETCONF服务器位于同一位置,系统组件:

  1. +-----------+ +-----------------+
  2. | Web app | <-------> | |
  3. +-----------+ RESTCONF | network device |
  4. | |
  5. +-----------+ | +-----------+ |
  6. | NETCONF | <-------> | | datastore | |
  7. | Client | NETCONF | | | |
  8. +-----------+ | +-----------+ |
  9. +-----------------+

下图显示了如果在没有NETCONF服务器的设备中实现RESTCONF服务器的系统组件:

  1. +-----------+ +-----------------+
  2. | Web app | <-------> | |
  3. +-----------+ RESTCONF | network device |
  4. | |
  5. +-----------------+

NETCONF协议​​和与编辑操作相关的RESTCONF协议​​之间存在交互。 RESTCONF服务器上有可能使用锁,尽管RESTCONF无法操作锁。在这种情况下,RESTCONF协议​​将不被授予对数据存储区内数据资源的写入访问权限。

如果NETCONF服务器支持:writable-running,则{+restconf}/data中对配置节点的所有编辑均在正在运行的配置数据存储中执行。第1.1.6节定义了URI模板“{+restconf}”。

否则,如果设备支持:candidate,则在{+restconf}/data中对配置节点的所有编辑均在候选配置数据存储中执行。候选人必须自动承诺在每次成功编辑后立即运行。候选数据存储中的其他来源的任何编辑也将被提交。如果任何NETCONF客户端正在执行确认的提交过程,则任何新的提交都将作为确认提交。如果NETCONF服务器需要一个“persist-id”参数来完成确认的提交过程,那么RESTCONF编辑操作必须失败并带有“409 Conflict”状态行。在这种情况下使用错误标签“使用中(in-use)”。

如果NETCONF服务器支持:startupRESTCONF服务器必须在由于RESTCONF编辑操作而导致“running”数据存储被改变之后自动更新非易失性启动配置数据存储。

如果由RESTCONF操作修改的数据存储具有来自NETCONF客户端的主动锁定,那么RESTCONF编辑操作必须失败并显示“409 Conflict”状态行。在这种情况下返回错误标记值“in-use”。