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

Question

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

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

我想知道的是，如果让我的CLI非常薄，那会有什么问题。它所做的就是将命令字符串发送到服务器，在那里验证，解释并返回响应字符串。

（甚至可以通过服务器的合作完成TAB完成。）

在我看来，这会简化开发并减少维护工作。

我有没有陷入困境？

<强>更新

可伸缩性问题不是重中之重。

Answer 1

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

Answer 2

一般情况下，您可以，但如果可以提前拒绝错误的请求，客户端验证是减少工作量的好方法。

Answer 3

  

我想知道的是，如果让我的CLI非常薄，会有什么不妥。

     

...

     

在我看来，这会简化开发并减少维护工作。

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

当然，如果真的没有要求客户端智能化（这听起来就像你的情况那样），这才真正适用。

Answer 4

在请求字符串中使用名称/值对实际上非常普遍。但是，在那一点上，为什么要烦恼SOAP呢？而只是转向RESTful架构？