我有一个客户端/服务器应用程序。其中一个客户端是 CLI。CLI 执行一些基本验证，然后向服务器发出 SOAP 请求。响应被解释并且相关信息被呈现给用户。每个命令都涉及对 Web 服务的请求。
每次在服务器端修改服务时，都需要发布一个新的 CLI。
我想知道的是，如果让我的 CLI 变得异常纤薄会不会有什么问题。它所要做的就是将命令字符串发送到服务器，在那里将对其进行验证、解释并返回响应字符串。
（即使是 TAB 完成也可以在服务器的配合下完成。）
我觉得在我的情况下，这将简化开发并减少维护工作。
有我忽略的陷阱吗？
更新
可扩展性问题不是高优先级。
一般来说，你会没事的，但是如果可以及早拒绝错误的请求，客户端验证是减少工作量的好方法。
我认为这真的只是一个品味问题。验证必须在某处进行；您只是在客户端的复杂性与软件中的相同复杂性之间进行权衡。这对你的架构来说不一定是坏事。您实际上只是提供了一项附加服务，为呼叫者提供了一种访问现有服务的替代方法。我要注意的唯一陷阱是代码重复。如果您发现您的 CLI 验证与您的某些服务执行相同的操作（例如解析数字），请重构以避免重复。
我想知道的是，如果让我的 CLI 变得异常纤薄会不会有什么问题。
...
我觉得在我的情况下，这将简化开发并减少维护工作。
多年来，人们一直在使用 telnet/SSH 远程处理在服务器上运行的 CLI。如果无论如何所有智能都必须在服务器上，那么可能没有理由让您的 CLI 成为具有智能的分布式客户端。让它成为一个终端会话 - 如果你可以使用 SSH，这就是我要做的 - 然后客户端部分完成一次（或者可能只是一个现成的软件）和所有的维护和升级发生在服务器上（欢迎来到 1978）。
当然，这仅在确实不需要客户聪明的情况下才真正适用（这听起来像您的情况）。
在请求字符串中使用名称/值对实际上非常普遍。但是，到那时，为什么还要使用 SOAP 呢？而是迁移到 RESTful 架构？