在 RustyVault 的 Surface 中增加 CLI 的接口，移除 Configuration Parese

[genedna]

@InfoHunter ，

对于架构设计的几个想法：

1. Surface 可以改为 Interface 层，接口层是比较通用的说法，容易被多数人理解
2. 提供 REST API 接口，需要有个 Daemon 存在于应用中，这个 Module 中需要画出来，当然将来也可以提供各种 PRC 调用的接口
3. 对于 Mega 项目，需要有一个 crate 的封装进行调用，不提供 endpoint 给开发者使用
4. 对于 Configuration Parese 是 HTTP Daemon 和 CLI 的基本功能，不必在 Interface 层表示
5. 建议为 RustyValut 提供一个 CLI 的接口，方便被其它项目集成

这里涉及到一个需要明确的问题：

RustyValut 是一个应用还是一个库？ 如果是一个应用，那么内部功能需要封装成 crate 给上层管理层级调用

[InfoHunter]

我理解CLI的本质其实就是一个命令行的程序，然后其实也是和RustyVault的REST API通信，从而实现各类功能

[InfoHunter]

@InfoHunter ，

对于架构设计的几个想法：

1. Surface 可以改为 Interface 层，接口层是比较通用的说法，容易被多数人理解

可以

2. 提供 REST API 接口，需要有个 Daemon 存在于应用中，这个 Module 中需要画出来，当然将来也可以提供各种 PRC 调用的接口

目前API Router里有这个daemon，本质上是个HTTP的server

3. 对于 Mega 项目，需要有一个 crate 的封装进行调用，不提供 endpoint 给开发者使用
4. 对于 Configuration Parese 是 HTTP Daemon 和 CLI 的基本功能，不必在 Interface 层表示
5. 建议为 RustyValut 提供一个 CLI 的接口，方便被其它项目集成

这里涉及到一个需要明确的问题：

RustyValut 是一个应用还是一个库？ 如果是一个应用，那么内部功能需要封装成 crate 给上层管理层级调用

是应用。这样的话看起来 RustyVault 的 Core 和 Module 部分应该是一个 Crate，这个 Crate 可以让外部创建一个或者多个比如叫做 RustyValue 的实例，然后其他 Rust 的应用就能用了

[InfoHunter]

图在processon上更新了一下

[genedna]

我理解CLI的本质其实就是一个命令行的程序，然后其实也是和RustyVault的REST API通信，从而实现各类功能

CLI 和 RESTFul API 应该都是调用相同的功能代码，而不是 CLI 调用 REST API 的接口去工作。

从 Docker 开始，很多系统都在提供 CLI 的同时提供一个本地的 REST API 的 Endpoint ，但是我认为 CLI 调用 Daemon 是一种错误的设计模式，CLI 应该去调用功能代码，可以提供 REST API 不合适提供的功能。譬如导出 Storage 的数据用于备份。

[genedna]

我对架构图进行了更新