そのため、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のすべてのオブジェクトに標準インターフェースを採用しない正当な理由があります。実用的な例に感謝します。

「動詞」と「名詞」の用語はここではやや不幸です。既に述べたように、機能用のオブジェクトを簡単に作成できます。Javaを除くすべてのオブジェクト指向言語にはその変換が組み込まれており、Javaでは常に1つのメソッドで「invoke」、「execute」、「apply」などと呼ばれる多くのオブジェクトが作成されます。 （つまり、「動詞」/「名詞」の区別が実際に意味をなさないプログラミング言語です）。

RESTの「動詞」は、メソッドをゲッター、セッター（削除者。セッターの一種と考えることができます）などに分類することに似ています。そして、ゲッターとセッターですべてをやろうとしています。その理由は次のとおりです。

1. ゲッターとセッターの両方がべき等であるため、通信障害に直面した場合のセマンティクスの簡素化。リソースを2回取得しても、追加の効果はなく、既にある値に設定することもありません。
2. 特定のインターフェイスを理解しないキャッシュプロキシによって使用される可能性のあるいくつかのセマンティクスを定義します。ゲッターはキャッシュされ、セッターはキャッシュを無効にすることが知られています。

HTTPは、キャッシュとフォールトトレランスの両方を念頭に置いて最初から設計されたため、これらの2つのポイントがHTTPの4つの基本的な方法につながります。

• GETゲッターです。有効期限と再検証ポリシーを指定する可能性があるたびに、サーバーの状態を変更せずに同じ値を返すことを前提としています。
• PUTそしてDELETE、セッターと削除者（= nilのセッター）です。通常、通常のWebのコンテキストでは使用されませんが、RESTには意味があります。
• POST キャッシュは何も想定できない汎用の「呼び出し」キッチンシンクです。

RESTは、生のHTTPまたは同様のネットワークプロトコルを使用して、単純な再試行による障害の容易な処理を可能にし、キャッシュプロキシとうまく機能するインターフェイスを実装する方法を説明する設計パターンです。

通常のオブジェクト指向プログラミングAPIには簡単に対応できません。実は良いことだと思います。本質的に信頼性が低く、インプロセスAPIとは異なる設計アプローチで中程度の量のデータコールを転送するよりも往復がはるかに遅いネットワーク経由のインターフェースの課題他のドメインからの無効な経験はそれだけです（それはSOAP、XML-RPCなどの悩みの種です;それはプロシージャ呼び出しのように見えますが、そのようには機能せず、作業するのが苦痛になります）。

基本的な考え方は、複雑さはリソース表現によって表現されるため、追加の動詞は必要ないということです。「RESTでは、名詞は良いが、動詞は悪い」という人もいます。

4つのREST動詞を見ると、基本的なCRUD操作にマッピングでき、基本的にリソースで何でもできます。あれは -

POST-リソースを作成します

GET-リソースを読み取ります

PUT-リソースを更新します

DELETE-リソースを削除します

他に何か要りますか？

すべての構成要素（関数など）がオブジェクトである言語を考えてください。次に、RESTful動詞は単に呼び出し規約と割り当てステートメントです。JavaScriptでは、関数を呼び出すINVOKE、別のオブジェクトのオブジェクトを削除するDELETE（jsのdeleteと同じ）、値を割り当てるSET、値を返すRETURNなどの固定動詞構文を定義できます。HTTP動詞を使用して、同等のPOST-関数の呼び出し、PUT-値の割り当て、GET-値の戻り、DELETE-オブジェクトの削除を意味できます。HTTPメソッドが実際にオブジェクトメソッド、実際のオブジェクトインターフェイスを記述しているという考えに巻き込まれ、明確に固定され有限である基本的な言語構造など、はるかに低いレベルの概念を実際に記述できるかどうかを確認できませんでした正気の言語。

そしてもちろん、ルーティング/プロキシが反映する固定語彙を持っていると役立ちます。

• プロのプログラマーは、そうでなければ数千ではないにしても数百のメソッド名を予測するからです。アプリケーションが大きくなるにつれて、小さな小さなサイズでは無意味に思えることは非常に大きな問題になります。

• メソッド名が既に定義されている場合、メソッド名に関する標準は必要ないからです。

• コードの主な目的は、このような追加の翻訳なしで読み取り可能であるためです。

• なぜなら、「いつ」別のクラスを分割すべきかを特定しやすくするためです。

• コードを引き継ぐとき、それが何をどのように行うかをより速く理解することは合理的であり、実際に可能です。

• 一般的な語彙と抽象化レベルを提供するため、他の詳細に集中してパターンを確認できます。

• 一般的なコードとアプローチを簡単にチェックできるため、バグの発見が容易になります。

• Web開発で使用するような複数の「レイヤー」で作業している場合、どのURLがどのアクション名に一致するかを知ることは、デバッグに非常に便利です。

全体的に「常に」必要なわけではありませんが、ほとんどの標準と同様に、それを使用しようとするのは理にかなっています！

代替手段は恐ろしいものです：WSDL（別名Webサービス定義言語）、これは（多少）任意のAPISをプログラムで記述する（扱いにくい）方法です。

RESTは動詞を厳しく制限し、ほとんどすべてのアプリケーション固有のバリエーションをドキュメントのペイロードにプッシュします。これを行うことの利点は、多くのクライアント実装が多くの異種サービスと通信できることです。クライアントとサーバーは互いに完全に不明な場合があり、一部はまだ作成されていません。

Stefan TilkovがRESTをうまく説明しているポッドキャストがあります。

はい、残りのAPIには動詞の固定セットがありますが、それに限定する必要はありません（またはGET、POST、PUT、DELETEを含む）。私は、GET、POST、PUT、DELETEをRESTのデフォルトの実装として見て、そこにあるすべてのシステムの80％で機能します。

crudオペレーションよりも多く実装している他のシステムは、REST APIのために独自の動詞を実装できます（そして実行します）。Publish、Consume、Rate、Comment、Search、Browseなどの動詞を追加して、RESTシステムに実装できます。語彙が多いほど複雑になるかもしれないと言う人もいるかもしれませんが、私の答えはそれが依存するということです。ターゲットユーザーが、POSTが何であるかを理解しているテクヘッドである場合、はい、より複雑になる可能性があります。ただし、APIのターゲットユーザーが本物の人（つまり、コーディングしておらず、POSTを知らない人）の場合、本物の動詞ははるかに使いやすいです。実際、APIに適切な動詞のセットがあると、URLを短くするのに役立ちます（ユーザーがブラウザーで入力するようにする場合に重要です。カスタム語彙を使用する場合は、d APIとその動詞が十分に文書化されていることを確認したい。カスタムREST APIを使用する場合、HTTP GETとしての「読み取り専用アクション」とPOSTによる「アクションの書き込み」を確実に行う必要があります。

10代のソーシャルネットワークであるPiczo.com（安心してご利用いただけます）は、7つの異なる言語で実装された拡張REST API（上記の動詞を含む）を備えていました！

シンプルが良い。

追加の動詞と複雑さが必要な場合もありますが、ほとんどの問題はリソースに対する単純なCRUDアクションに切り詰めることができ、それがRESTが促進しようとするものです。ほとんどのWebアプリケーションについて考えると、最終的にそれらは同じ非常に単純なアクションを使用するデータストアでレコードを読み取り、永続化します。

object.foo（）はすべて良いですが、何をしますか？それは何を返していますか？オブジェクトまたはその依存関係の状態を変更していますか？2回呼び出して同じ結果を得ることができますか、それとも2つの異なる値を与えることができますか？object.bar（）もある場合、特定の順序で呼び出す必要がありますか？

リッチAPIを使用するには多くの知識が必要であり、通常は独自の規則があります（つまり、setFooはオブジェクトを変更します。などが可能になります...）