1.4. 与NETCONF共存

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

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

+-----------+           +-----------------+
|  Web app  | <-------> |                 |
+-----------+  RESTCONF | network device  |
                        |                 |
+-----------+           |   +-----------+ |
| NETCONF   | <-------> |   | datastore | |
| Client    |  NETCONF  |   |           | |
+-----------+           |   +-----------+ |
                        +-----------------+

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

+-----------+           +-----------------+
|  Web app  | <-------> |                 |
+-----------+  RESTCONF | network device  |
                        |                 |
                        +-----------------+

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服务器支持:startup，RESTCONF服务器必须在由于RESTCONF编辑操作而导致“running”数据存储被改变之后自动更新非易失性启动配置数据存储。

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