どうやら、RESTはHTTPの使い方に関する規則の集まりにすぎません。これらの規則が提供する利点はどれかと思います。誰か知っている？

REST が何であるかについて誰も本当に同意していないという理由もあって、あなたはこれに対して良い答えを得るとは思いません。Wikipediaのページには、説明の流行語と光に重いです。ディスカッションページは、人々がこれについてどの程度意見を異にしているのかを確認するだけでも、一見の価値があります。ただし、私が知る限り、RESTは次のことを意味します。

代わりに、ランダムな名前のセッターとゲッターのURLを有し、かつ使用するGETすべてのゲッターのためにとPOST、すべてのセッターのために、我々は、URLがリソースを特定し、HTTPアクションを使用していしようとGET、POST、PUTおよびDELETEそれらにものを行うために。だから代わりに

GET /get_article?id=1
POST /delete_article   id=1

あなたはするだろう

GET /articles/1/
DELETE /articles/1/

そしてPOSTそしてPUT、「作成」および「更新」操作（誰もが道のラウンドを同意していない）に対応しています。

クエリ文字列は一般的にキャッシュされるため、キャッシュ引数は間違っていると思います。また、実際に使用する必要はありません。たとえば、djangoを使用すると、このようなことが非常に簡単になり、RESTだとは言えません。

GET /get_article/1/
POST /delete_article/     id=1

または、URLに動詞を含めるだけでもかまいません。

GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/

その場合GET、副作用のないPOSTものを意味し、サーバー上のデータを変更するものを意味します。これはおそらく特に明確で簡単です。特に、PUTvs- 全体を回避できるためPOSTです。さらに、必要に応じて動詞をさらに追加できるため、HTTPが提供するものに人為的に縛られることはありません。例えば：

POST /hide/article/1/
POST /show/article/1/

（または何であれ、それらが発生するまで例を考えるのは難しい！）

結論として、私が見ることができる利点は2つだけです。

1. Web APIはよりクリーンで理解しやすく、発見しやすいかもしれません。
2. Webサイトとデータを同期する場合、RESTを使用するほうがおそらく簡単ですsynchronize("/articles/1/")。これは、コードに大きく依存します。

ただし、かなり大きな欠点がいくつかあると思います。

1. すべてのアクションが簡単にCRUDにマッピングされるわけではありません（作成、読み取り/取得、更新、削除）。オブジェクトタイプのリソースを扱っていないこともあります。
2. 疑わしい利益のための余分な努力です。
3. どの方法ラウンドのように混乱PUTしてPOSTいます。英語では似たような意味です（「私は壁に通知を貼る/掲示します。」）。

したがって、結論として私は言います。本当に余分な労力を費やしたくない場合、またはサービスがCRUD操作にうまく対応している場合を除き、APIの2番目のバージョンのRESTを保存します。

RESTに関する別の問題に遭遇しました。1つの要求で複数のことを実行したり、取得したい複合オブジェクトの部分を指定したりすることは簡単ではありません。これは、往復時間が非常に長く、接続の信頼性が低いモバイルでは特に重要です。たとえば、Facebookのタイムラインに投稿を取得しているとします。「純粋な」RESTの方法は次のようになります

GET /timeline_posts     // Returns a list of post IDs.
GET /timeline_posts/1/  // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....

それはちょっとばかげています。FacebookのAPIはかなり優れたIMOなので、何をするか見てみましょう。

デフォルトでは、クエリを実行すると、ほとんどのオブジェクトプロパティが返されます。"fields"クエリパラメータを使用して、返すフィールド（または接続）を選択できます。たとえば、次のURLはベンのID、名前、写真のみを返します。https：//graph.facebook.com/bgolub？fields = id、name、picture

RESTでそのようなことをどのように行うのか、また、RESTとしてカウントされるかどうかはわかりません。私はあなたがそれをしてはいけないと言ってくれる人を絶対に無視します（特に、理由が「RESTではないため」の場合）！

簡単に言えば、RESTは本来の方法でHTTPを使用することを意味します。

見ていRESTに関するロイフィールディングの論文を。私はウェブ開発をしているすべての人がそれを読むべきだと思います。

メモとして、ロイフィールディングもHTTPプロトコルの背後にある主要なドライバーの1つです。

いくつかのアドバンテージに名前を付けるには：

• シンプル。
• 高負荷を処理するのに役立つHTTPキャッシュとプロキシサーバーをうまく利用できます。
• 非常に複雑なアプリケーションでも単純なリソースに整理するのに役立ちます。
• 新しいクライアントがアプリケーションを特別に設計していなくても、簡単にアプリケーションを使用できるようになります（おそらく、アプリケーションを作成したときに周りになかったためです）。

簡単に言えません：NONEを。

遠慮なく投票してください。ただし、REST以外のHTTPに勝る本当のメリットはないと私は思います。現在の回答はすべて無効です。現在最も投票されている回答の議論：

• シンプル。
• 高負荷を処理するのに役立つHTTPキャッシュとプロキシサーバーをうまく利用できます。
• 非常に複雑なアプリケーションでも単純なリソースに整理するのに役立ちます。
• 新しいクライアントがアプリケーションを特別に設計していなくても、簡単にアプリケーションを使用できるようになります（おそらく、アプリケーションを作成したときに周りになかったためです）。

1.シンプル

RESTを使用する場合、サーバー側とクライアント側のスクリプトに追加の通信レイヤーが必要です=>実際には、非REST HTTPを使用するよりも複雑です。

2.キャッシング

キャッシュは、サーバーから送信されるHTTPヘッダーによって制御できます。RESTは、非RESTに欠けている機能を追加しません。

3.組織

RESTは、物事を整理するのに役立ちません。それは強制的にあなたが使用しているサーバー側のライブラリでサポートされているAPIを使用します。REST以外のアプローチを使用する場合も、同じ方法（またはそれ以上）でアプリケーションを編成できます。たとえば、Model-View-ControllerまたはMVCルーティングを参照してください。

4.使いやすく、実装も簡単

まったく当てはまりません。それはすべて、アプリケーションをどれだけうまく整理して文書化するかにかかっています。RESTがアプリケーションを魔法のように改善することはありません。

RESTによって可能になる最大の利点は、クライアント/サーバーの結合を減らすことです。既存のクライアントを壊すことなく、時間の経過とともにRESTインターフェースを進化させる方がはるかに簡単です。

発見可能性

各リソースは、階層またはリンクで他のリソースへの参照を持っているため、簡単に参照できます。これは、クライアントを開発する人間にとって利点であり、常にドキュメントを参照したり、提案を提供したりする必要がありません。これは、サーバーがリソース名を一方的に変更できることも意味します（クライアントソフトウェアがURLをハードコーディングしない限り）。

他のツールとの互換性

APIの任意の部分にCURLするか、Webブラウザーを使用してリソースをナビゲートできます。デバッグとテストの統合をはるかに簡単にします。

標準化された動詞名

正しい言い回しを探す必要なしに、アクションを指定できます。OOPのゲッターとセッターが標準化されておらず、一部の人々が代わりに使用していたretrieveと想像してくださいdefine。個々のアクセスポイントごとに正しい動詞を覚えておく必要があります。その問題に対応できる動詞はごくわずかしかないことを知っている。

標準化されたステータス

GET存在しないリソースの場合404、RESTful APIでエラーが発生する可能性があります。それを、RESTfulでないAPIと比較してください。これは{error: "Not found"}、神に包まれて返される可能性があるので、レイヤーの数を知っています。反対側の開発者にメッセージを書き込むために追加のスペースが必要な場合は、常に応答の本文を使用できます。

例

同じ機能を持つ2つのAPIを想像してください。1つはRESTに従い、もう1つはRESTに従いません。これらのAPIの次のクライアントを想像してください。

RESTful：

GET /products/1052/reviews
POST /products/1052/reviews       "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10

HTTP：

GET /reviews?product_id=1052
POST /post_review?product_id=1052                  "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10

次の質問について考えてみましょう。

• 各クライアントの最初の呼び出しが機能した場合、残りの部分も確実に機能しますか？

• APIに大きなアップデートがあり、それらのアクセスポイントが変更された可能性があります。どのくらいのドキュメントを再読する必要がありますか？

• 最後のクエリの戻りを予測できますか？

• （削除する前に）投稿されたレビューを編集する必要があります。あなたはドキュメントをチェックせずにそうすることができますか？

Ryan TomaykoのHow I Explained REST to My Wifeをご覧になることをお勧めします

サードパーティ編集

waybackmaschineリンクからの抜粋：

例はどうですか。あなたは教師であり、生徒を管理したい場合：

• 彼らがどのクラスにいるか
• 彼らが得ている成績、
• 緊急連絡先、
• 教える本に関する情報など

システムがWebベースの場合、関連する各名詞のURLはおそらくここにありますstudent, teacher, class, book, room, etc。...各URLに機械で読み取り可能な表現がある場合、すべての情報が標準的な方法で利用できるため、新しいツールをシステムにラッチするのは簡単です。...全国的なシステムを構築して、個々の学校システムと対話してテストのスコアを収集することができます。

各システムは、単純なHTTP GETを使用して相互に情報を取得します。あるシステムが別のシステムに何かを追加する必要がある場合は、HTTP POSTを使用します。システムが別のシステムの何かを更新したい場合は、HTTP PUTを使用します。残っている唯一のことは、データがどのように見えるかです。

この質問への回答を探しているすべての人が、この「スライドショー」に参加することをお勧めします。

RESTとは何か、なぜRESTfulであるか、その長所と短所、SOAPとの違いが理解できませんでした。しかし、このスライドショーはとても素晴らしく、理解しやすかったので、以前よりはるかに明確になりました。

キャッシング。

RESTには、疎結合とハイパーテキストを介して進化可能性を中心に展開する他の詳細な利点がありますが、キャッシュメカニズムがRESTful HTTPを気にする必要がある主な理由です。

それはフィールディングの論文に書き留められています。しかし、多くを読みたくない場合：

• スケーラビリティの向上（ステートレス、キャッシュ、および階層化システムの制約による）
• 分離されたクライアントとサーバー（ステートレスで統一されたインターフェース制約による）
  • 再利用可能なクライアント（クライアントは、一般的なRESTブラウザとRDFセマンティクスを使用して、どのリンクをたどるか、結果を表示する方法を決定できます）
  • 非破壊クライアント（クライアントは、API固有の知識ではなくセマンティクスを使用するため、アプリケーション固有のセマンティクスの変更によってのみ破壊されます）

• すべての「リソース」にIDを与える
• 物事をリンクする
• 標準的な方法を使用する
• 複数の表現を持つリソース
• ステートレスに通信する

POSTとGETだけですべてを実行できますか？はい、それは最善のアプローチですか？いいえ、なぜですか？標準的な方法があるからです。もう一度考えてみると、GETだけですべてを実行できる可能性があります。では、なぜPOSTを使用する必要があるのでしょうか。基準のために！

たとえば、今日のMVCモデルについて考えると、POST、GET、PUT、DELETEなどの特定の種類の動詞にのみ応答するようにアプリケーションを制限できます。内部ですべてがPOSTとGETにエミュレートされている場合でも、異なるアクションに対して異なる動詞を使用するのは意味がありませんか？

RESTでは発見がはるかに簡単です。サービスを世界に宣伝するのに役立つWADLドキュメント（従来のWebサービスのWSDLに類似）があります。UDDIディスカバリーも使用できます。従来のHTTP POSTおよびGETの場合、ユーザーはあなたを呼び出すためのメッセージ要求スキーマと応答スキーマを知らない場合があります。

1つの利点は、InputStreamオブジェクト、URL、DOMノードなどのさまざまなソースからのXMLドキュメントを非順次に処理し、XMLデータを非整列化できることです...

@Timmmm、あなたの編集について：

GET /timeline_posts     // could return the N first posts, with links to fetch the next/previous N posts

これは呼び出しの数を劇的に減らします

そして、クライアントが望むフィールド値を示すためにHTTPパラメータを受け入れるサーバーを設計することを妨げるものは何もありません...

しかし、これは詳細です。

さらに重要なのは、RESTアーキテクチャスタイルの大きな利点について言及しなかったという事実です（サーバーのステートレス性によるスケーラビリティの向上、サーバーのステートレス性による可用性の大幅な向上、キャッシュなどの標準サービスの使用の大幅な向上）。インスタンス、RESTアーキテクチャスタイルを使用する場合、統一されたインターフェースの使用などにより、クライアントとサーバー間の結合がはるかに低くなります。

あなたの発言は

「すべてのアクションがCRUDに簡単にマッピングされるわけではありません（作成、読み取り/取得、更新、削除）。」

：RDBMSもCRUDアプローチ（SELECT / INSERT / DELETE / UPDATE）を使用しており、常にデータモデルを表現して操作する方法があります。

あなたの文について

「オブジェクトタイプのリソースを扱っていないこともある」

：RESTfulなデザインは、本質的にシンプルなデザインですが、デザインがシンプルであることを意味するものではありません。違いがわかりますか？リソースでこれを表現するには、アプリケーションが表現および処理する概念、必要に応じてアプリケーションが実行する必要があることについて、多くのことを考える必要があります。しかし、そうすると、最終的にはよりシンプルで効率的な設計になります。

検索エンジンはクエリ文字列を無視できます。