CLI検証/ロジックサーバー側の移動に問題はありますか？

Question

クライアント/サーバーアプリケーションがあります。クライアントの1つはCLIです。 CLIはいくつかの基本的な検証を実行してから、サーバーにSOAP要求を行います。応答は解釈され、関連情報がユーザーに提示されます。すべてのコマンドには、Webサービスへのリクエストが含まれていました。

サーバー側でサービスが変更されるたびに、新しいCLIをリリースする必要があります。

私が思っているのは、CLIを非常に薄くすることに問題があるかどうかです。コマンド文字列をサーバーに送信するだけで、コマンド文字列が検証、解釈され、応答文字列が返されます。

（TABの補完でさえ、サーバーの協力で行うことができます。）

私の場合、これにより開発が簡素化され、メンテナンス作業が軽減されると思います。

見落としている落とし穴はありますか？

更新

スケーラビリティの問題は最優先事項ではありません。

Answer 1

これは本当に好みの問題だと思います。検証はどこかで行わなければなりません。クライアントの複雑さをソフトウェアの同じ量の複雑さと引き換えにしています。それはあなたのアーキテクチャにとって必ずしも悪いことではありません。実際には、発信者が既存のサービスにアクセスする代替手段を提供する追加サービスを提供しているだけです。私が探している唯一の落とし穴は、コードの複製です。 CLI検証がサービスの一部と同じことを実行していることがわかった場合（数値の解析など）、重複を避けるためにリファクタリングします。

Answer 2

一般的には問題ありませんが、クライアント側の検証は、不適切なリクエストを早期に拒否できる場合にワークロードを削減するための良い方法です。

Answer 3

  

私が疑問に思っているのは、CLIを非常に薄くすることに問題があるかどうかです。

     

...

     

私の場合、これにより開発が簡素化され、メンテナンス作業が軽減されると思います。

人々はこれを長年、telnet / SSHを使用して、サーバーで実行されるCLIのリモート処理に使用しています。とにかくすべてのインテリジェンスがサーバー上になければならない場合、CLIをインテリジェンスを備えた分散クライアントにする理由はないかもしれません。ターミナルセッションにするだけです-SSHを使用して逃げることができれば、それが私がすることです-クライアント部分は1回（または場合によっては市販のソフトウェア）だけで、すべてのメンテナンスとアップグレードはサーバー上で行われます（1978年へようこそ）。

もちろん、これは本当にクライアントがインテリジェントである必要がない場合にのみ適用されます（これはあなたの状況の場合のように聞こえます）。

Answer 4

リクエスト文字列で名前/値のペアを使用することは、実際にはかなり重要です。しかし、その時点で、なぜSOAPに悩まされるのでしょうか？代わりに、RESTfulアーキテクチャに移行するだけですか？