移动 CLI 验证/逻辑服务器端有什么问题吗？答案

【问题标题】：Anything wrong with moving CLI validation/logic server-side?移动 CLI 验证/逻辑服务器端有什么问题吗？
【发布时间】：2009-01-09 20:01:08
【问题描述】：

我有一个客户端/服务器应用程序。其中一个客户端是 CLI。 CLI 执行一些基本验证，然后向服务器发出 SOAP 请求。响应被解释并且相关信息被呈现给用户。每个命令都涉及对 Web 服务的请求。

每次在服务器端修改服务时，都需要发布新的 CLI。

我想知道的是，让我的 CLI 变得异常纤薄会不会有什么问题。它所要做的就是将命令字符串发送到服务器，在那里将对其进行验证、解释并返回响应字符串。

（即使是 TAB 完成也可以在服务器的配合下完成。）

我觉得这会简化开发并减少维护工作。

有没有我忽略的陷阱？

更新

可扩展性问题不是高优先级。

【问题讨论】：

标签： client-server command-line-interface

【解决方案1】：

我认为这真的只是一个品味问题。验证必须在某处进行；您只是在客户端的复杂性与软件中的相同复杂性之间进行权衡。这对你的架构来说不一定是坏事。您实际上只是提供了一项附加服务，为呼叫者提供了一种访问现有服务的替代方式。我要注意的唯一陷阱是代码重复。如果您发现您的 CLI 验证与您的某些服务执行相同的操作（例如解析数字），请重构以避免重复。

【讨论】：

【解决方案2】：

一般来说，你会没事的，但如果可以及早拒绝错误的请求，客户端验证是减少工作量的好方法。

【讨论】：

换句话说：胖客户端可以更好地扩展。
忘了补充一点，无论如何，您可能也应该在服务器端进行所有这些验证。您永远不知道何时有人会开始尝试向您的服务发送恶意请求。

【解决方案3】：

我想知道的是，让我的 CLI 变得异常纤薄会不会有什么问题。

...

我觉得这会简化开发并减少维护工作。

多年来，人们一直在使用 telnet/SSH 远程处理在服务器上运行的 CLI。如果无论如何所有智能都必须在服务器上，那么可能没有理由让您的 CLI 成为具有智能的分布式客户端。让它成为一个终端会话 - 如果你可以使用 SSH，这就是我要做的 - 然后客户端部分完成一次（或者可能只是一个现成的软件）和所有的维护和升级发生在服务器上（欢迎来到 1978）。

当然，这仅适用于确实不需要客户端聪明的情况（听起来像您的情况）。

【讨论】：

【解决方案4】：

在请求字符串中使用名称/值对实际上非常普遍。但是，到那时，为什么还要使用 SOAP 呢？而是直接迁移到 RESTful 架构？

【讨论】：