私が何度か参加したことのある長年の論争があり、それは今のところ未解決のままです。 ここで既存の議論を紹介します。コメントと追加の議論に興味を持って聞きます。
だから
論文1：RESTは良い、* -RPC（XML-RPC、JSON-RPCなど）は悪い。
論文2：なぜなら RESTは優れており、仮想マシン（特にクラウド）の管理に使用する必要があります。
一見そうです。 たとえば、仮想マシンの属性（「ブートディスク」属性など）を変更する場合、次のように記述します。
PUT ... / vm333 / disk1 /ブータブル enable = true PUT ... / vm333 / disk1 /ブータブル enable = false
またはこのように：
POST / vm / 333 / disk1 /ブータブル DELETE / vm333 / disk1 /ブータブル
ディスクを作成する場合、POST / vm333 / disk2と言い、属性（サイズやストレージなど）を渡します。
ただし、これは、インフラストラクチャがデータベースエントリに類似している場合にのみ有効です。
簡単な質問：仮想マシンの再起動コマンドはRESTではどのようになりますか？ 結局のところ、マシンの状態は変更されず、実行中だったため、そのまま残ります。 明らかに、再起動はべき等呼び出しではありません。つまり、POSTと言う必要があります。 しかし、「何をどこに入れますか？」 シャットダウン/起動でさえ、POSTの電源状態に完全に適合することに注意してください。 しかし、ここに再起動があります-これはデータベース内のオブジェクトの状態の「内在」の論理に違反し、残酷な命令世界に私たちを導きます-残念ながら、それらは適合しません。 操作 'install'（OSインストールの開始）中に同様の問題が発生します。
ここでの理由は、「それがあまり得意ではない」よりもはるかに深いです。 「オントロジー」という言葉で申し訳ありませんが、この理由は存在論的です。
問題の本質
クラウド内（および実際、サーバー管理ファーム内）のオブジェクトは、データベース内の行ではありません。 彼らは自分たちの生活を送っており、私たちのデータベース（RESTインターフェースをアタッチしようとしている）に見えるものは、この生活の単なる反映です。データベース内の属性の一部は信頼できる値です。 たとえば、このマシンが「foobar」と呼ばれると言った場合、そのマシンは「foobar」と呼ばれます。 そして、黒人の意見は保安官に喜びを与えません。 ただし、たとえば、「実行中」の状態を考慮してください。 結局のところ、これは仮想マシンを管理するためのデータベースの「属性」ではありません。 これは_eyo_、彼女の個人状態です。 彼女が望んでいるように、そうです。 彼は最初に落ちたいと思っています-power-state属性を 'running'の値に実行して実行させることはできません。 同様に他の多くの質問もあります。「32 MBのメモリを作る」と言うことができますが、仮想マシンは48 MBコアが占有するメモリを見て「ありがとう、必要ありません」と言って64 MBで停止できます。 属性「32 MB」を記録し、そこに「64 MB」を記録しました。 そして最悪の部分は、それが「配達に失敗した」状況ではなく、取引を拒否したことです。 これは「彼女ができること、彼女がやったこと」。 はい、そして遅れて-最初の96MB、次に82、そして20〜64分後にだけです。さらに、私たちが本当に緊張していて、まだ車を作るなら（より正確には、マシンは「頭を考えない」でしょう） ）、32MBの代わりにpower-state = crashedを取得します。 予想される32MBの代わりに。 ナンセンス。 データベースではなく、ある種のポルノ。
その理由は、書き込み先のデータベースがデータベースではないためです。 これらは私たちの信頼できる意味です（名前と番号など、仮想マシンが完全に起動していること、そしてここでは少し疑いのない本当のDBです）、これらはマシンの制限です（マシンはバイパスしようとしますが、DBも動作しません） ）そして、これらは機械が満たそうとするかもしれないという私たちの願いですが、 うまくいかないかもしれません し、最後には出 ないかもしれません 。
したがって、私たちは、素直なデータベースとの関係のRESTイデオロギーと現実世界との関係の本質に矛盾を見る。
RPCは世界を救いますか？
この場合、命令型アプローチははるかに合理的に見えます-リモート（命令型）関数を「呼び出し」て引数を渡すあらゆる種類のRPCの使用。この場合、「彼らは1つのことを変え始め、別のことが判明しました」ははるかに論理的に見えます。 特に、vm.set_memory（）の代わりにvm.send_desired_mem（）を実行する場合。 最初のチームはナンセンスを出すことができ、2番目のチームは決してできません。 彼らは、合格した数を渡すと言いました。 次に起こることはVMに依存します。 この場合、オントロジーの問題を解決します-管理対象オブジェクトの独立の権利を認識します（可能な場合-許可/無効化、不可能な場合-実際の状態を修正します）。
しかし、RPCは、データベース内の関係を熟考するのではなく、重く、不快であり、主題領域について考えるようになるため、当然scられます。
この時点で、美しいストーリーが途切れ、そのコメントがコメント者に伝えられます。