固定の小さな語彙がRESTfulサービスの利点と見なされるのはなぜですか？
そのため、RESTfulサービスの語彙には動詞の固定セットがあります。RESTful Webサービスは、HTTPメソッドからこれらを取得します。固定語彙を定義することにはいくつかの利点があると思われますが、私はその点を本当に理解していません。たぶん誰かがそれを説明できるでしょう。 RESTで概説されている固定語彙が、各状態の語彙を動的に定義するよりも優れているのはなぜですか？たとえば、オブジェクト指向プログラミングは一般的なパラダイムです。RPCは固定インターフェースを定義するために記述されていますが、なぜ人々はRPCがこれらの制約によって制限されていると仮定するのか分かりません。RESTfulサービスがそのコンテンツ構造を動的に記述するように、インターフェイスを動的に指定できます。 RESTは、語彙を増やすことなく成長できるという点で有利であると考えられています。RESTfulサービスは、リソースを追加することで動的に成長します。オブジェクトごとの語彙を動的に指定してサービスを拡張することの何がそんなに悪いのでしょうか？オブジェクトでボキャブラリーとして定義されているメソッドを使用し、これらのメソッドが何であり、副作用があるかどうかをクライアントにサービスで説明させてみませんか？ 基本的に、サーバー側のリソース構造の記述は語彙の定義と同等であると感じますが、これらのリソースとやり取りするために限られた語彙を使用せざるを得ません。 固定語彙は、クライアントの懸念をサーバーの懸念から本当に切り離しますか？確かにサーバーの構成に注意する必要があります。これは通常、RESTfulサービスのリソースの場所です。動的ボキャブラリーの使用に不満を言うことは、とにかく何らかの方法でこの構成を理解する方法を動的に推論する必要があるため、不公平に思えます。RESTfulサービスは、ハイパーメディアを介してオブジェクト構造を識別することによって実行できる遷移を記述します。 固定語彙が、自己記述型の動的語彙よりも優れている理由がわかりません。これは、RPCのようなサービスで簡単にうまく機能する可能性があります。これは、HTTPプロトコルの語彙が制限されていることの不十分な理由にすぎませんか？ 反射 私の考えを私がやったよりも少し良くするためだけに。おそらく汎用のAPIを設計していると仮定します。Web向けではないかもしれません。オブジェクトでこれらのメソッド名しか使用できないと誰かが言ったら、あなたは幸せになりますか？RESTはHTTPに限定されるものではありませんが、作成するすべてのAPI、Web向け、または単純にGET POST PUTおよびDELETEメソッドを含むオブジェクトで構成される状況を考慮してください。そのため、定義したいobject.fooメソッドは不可能です。fooという新しいオブジェクトを定義し、そのGETメソッドを呼び出す必要があります。それが本質的にRESTの仕組みであり、それについて考えるのが少し不快になります。fooが何をするかについての一般的な理解はありません。基本的には親オブジェクトのメソッドである新しいオブジェクトを作成するように強制されました。さらに、APIはそれほど複雑ではありません。より多くのオブジェクトを作成することにより、インターフェイスの複雑さが隠されているだけです。RESTful Webサービスでは、公開しているAPIのコンテキストでは十分である場合とそうでない場合があります。おそらく、Webに面したAPIでこれを行う正当な理由があるかもしれませんが、すべての汎用APIのすべてのオブジェクトに標準インターフェースを採用しない正当な理由があります。実用的な例に感謝します。