クライアント/サーバー アプリケーションがあります。クライアントの 1 つは CLI です。CLI はいくつかの基本的な検証を実行し、サーバーに対して SOAP 要求を行います。応答が解釈され、関連情報がユーザーに表示されます。すべてのコマンドには、Web サービスへの要求が含まれていました。
サービスがサーバー側で変更されるたびに、新しい CLI をリリースする必要があります。
私が疑問に思っているのは、CLI を信じられないほど薄くすることに何か問題があるのではないかということです。コマンド文字列をサーバーに送信するだけで、サーバーで検証、解釈され、応答文字列が返されます。
(サーバーの連携でTAB補完もできました。)
私の場合、これにより開発が簡素化され、メンテナンス作業が軽減されると感じています。
私が見落としている落とし穴はありますか？
アップデート
スケーラビリティの問題は優先度が高くありません。
一般的には問題ありませんが、クライアント側の検証は、不適切な要求を早期に拒否できる場合に作業負荷を軽減する良い方法です。
これは本当に好みの問題だと思います。検証はどこかで行う必要があります。クライアントの複雑さとソフトウェアの複雑さをトレードオフしているだけです。これは、アーキテクチャにとって必ずしも悪いことではありません。実際には、発信者が既存のサービスにアクセスするための代替手段を提供する追加のサービスを提供しているだけです。私が注意したい唯一の落とし穴は、コードの重複です。CLI 検証が一部のサービスと同じことを行っていることがわかった場合 (たとえば、数値の解析)、重複を避けるためにリファクタリングします。
私が疑問に思っているのは、CLI を信じられないほど薄くすることに何か問題があるのではないかということです。
...
私の場合、これにより開発が簡素化され、メンテナンス作業が軽減されると感じています。
サーバー上で実行される CLI をリモート処理するために telnet/SSH を使用して、人々は何年もこれを行ってきました。とにかくすべてのインテリジェンスがサーバー上になければならない場合、CLI をインテリジェンスを備えた分散クライアントにする理由はないかもしれません。端末セッションにするだけです-SSHを使用して逃げることができれば、それが私がすることです-その後、クライアント部分は1回（またはおそらく既製のソフトウェアのビット）で完了し、すべてのメンテナンスとアップグレードはサーバー上で行われます (1978 へようこそ)。
もちろん、これは、クライアントがインテリジェントである必要がない場合にのみ実際に適用されます（これは、あなたの状況のように聞こえます）。
リクエスト文字列で名前と値のペアを使用することは、実際にはかなり一般的です。しかし、その時点で、なぜ SOAP を気にするのでしょうか? 代わりに、RESTful アーキテクチャに移行するだけですか?