3

だから、私はRubyonRailsを学んでいます。アプリケーションアーキテクチャへのRESTfulアプローチの基本を理解しましたが、RESTfulアプリケーションを完全に構築していません。

従来のWebアプリケーションでは、べき等要求（状態を変更しない）はHTTPのGETメソッドを介して行われ、すべての非べき等要求は通常、POSTメソッドを介して行われます。POSTアプリケーションがリクエストによってトリガーされる可能性のあるさまざまなアクションを区別するために、通常、またはPOSTのように、リクエストに含まれるフォームに非表示のフィールドがあります。これはかなり単純なアーキテクチャであり、今日ではかなり一般的ですが、RESTアプローチはこれから私たちを遠ざけ、これが「すべてをPOSTしましょう」ことを示唆しています。デザインは有害であると見なされます。action=deleteaction=add_to_foo_file

代わりに、RESTfulアーキテクチャでは、リクエスト内の別のフィールドに基づいて実行するアクションを決定する代わりに、リソースを一意に識別するURI（名詞）とHTTPリクエストメソッド（動詞）を介してリソースを操作します。

GET    => show the resource
PUT    => update the resource
POST   => create a new resource
DELETE => destroy the resource

では、RubyonRailsについて説明します。RailsではPUT、DELETEJavaScriptによって実装されます。JavaScriptは、リンクを。と呼ばれる非表示フィールドを持つフォームに変更します_method。フォームはブラウザからPOST、を介して受信され、Railsはこのフィールドを探して、リクエストをコントローラのPUTまたはDELETEメソッドにルーティングするかどうかを決定します。

待って、何？POSTこれは、レコードを破棄するか変更するかを決定するために特定のフィールドを介してすべての状態変更要求を受信し、検査する従来のWebアプリケーションの動作とまったく同じように不審に聞こえます。

では、RailsのアプローチはRESTfulであるとどのように言えますか？内部的には、RESTが具体的に離れようとしている「すべてをPOSTしよう」アプローチの再実装にすぎないからです。

さらに、このアプローチは、ブラウザーでJSがオフになっているユーザーに対して、私のRailsアプリが正常に劣化するのを防ぎませんか？

4

3 に答える 3

4

システムをRESTfulにするかどうかは、使用する動詞ではありませんが、対話がハイパーメディア（この場合、コードオンデマンドJavaScriptを含む）によって駆動されるという事実です。

引用しているGET/PUT / POST / DELETEマッピングは、CRUD操作では正常に機能しますが、必ずしもすべてに適しているわけではありません（また、すべてのブラウザーでサポートされているとは限りません）。これは、RESTfulシステムを設計するための合理的な経験則ですが、十分でも必要でもありません。（これは、「RESTful」URIが必要なときに人々が主張するものと同じカテゴリのアイデアです。そのようなものはありません。）

この一部は、 RESTfulWebサービスなどの書籍の影響を受けます。良い本ですが、WS-* / SOAPが主流で、すべてがPOSTを介してトンネリングされたときに出てきました。SOAPに対する反応は、使用できる他のHTTP動詞があることを人々に認識させることでした。

RESTの場合、特に重要なのは、URIの概念の背後にある概念、各HTTP動詞のセマンティクス（副作用なし、べき等要求、...、必要に応じて、HTTPを使用している場合）、およびHATEOSを尊重することです。原理。これはアーキテクチャスタイルであり、JavaScriptが実行するPOST / PUT/DELETEについてあまり強調しないでください。

あなたは確かにこれらを読むべきです：

編集:(以下のコメント）

私が言わなければならないことはこれでした：ほとんどのフレームワークがに変わるならばDELETE http://server.tld/resource/1、そもそもPOST http://server.tld/resource/1?_method=DELETE単に使用することに対するそのアプローチの利点は何ですか？POST http://server.tld/resource/1?my_method=delete

  • これにより、API設計の観点から、全体的な目標が少し明確になります。RESTはアーキテクチャスタイルであり、プロトコルや実装ではないため、RESTフレームワークは、最終的には使用するのと同じくらいRESTfulにすることができます。
  • さらに、厳密に言えば、URIにはクエリコンポーネントが含まれているためhttp://server.tld/resource/1、http://server.tld/resource/1?my_method=DELETE原則としてさまざまなリソースを識別できます（ただし、これは適切な設計上の選択ではありません）。

  • DELETEフレームワークが/PUTを直接公開できるのは良いことですが、POSTそれをサポートしていないクライアントのためのフォールバックソリューションがあります。

    この理由は、サポートDELETE/を行うクライアントPUTがそれらを利用し、それらの使用法について推測できるようになるためです。原則としてべき等であったとしても、クライアントが要求を非べき等として扱うことはそれほど問題ではありません。クライアントが、要求のN + 1を送信できたときに、最大で1つの要求（べき等ではない）を送信できると考えている場合、これは大きな問題を引き起こしません。クライアントが、べき等であってはならないものに対して同じ要求をN + 1回送信できると考える場合、これは非常に多くの問題を引き起こす可能性があります。PUTスルーをエミュレートすることPOSTはOKです、あなたはただ最大限に活用していません、スルーをPUTエミュレートすることは問題があるでしょう。POSTPUT

于 2012-07-27T19:12:57.443 に答える
1

もちろん、Railsは適切なHTTP動詞（そしてすぐにPATCHも）をサポートします。唯一の問題は、ブラウザはGETとPOSTしかサポートしていないため、サポートしていないということです。この制限を回避するために、Railsは、説明した_methodパラメーターで実際のHTTP動詞を「オーバーライド」する追加機能を提供します。

APIを使用する主で適切な方法は、代わりに実際のHTTP動詞を使用することです。有能なクライアントがあれば、これを行うことができ、またそうすることが奨励されます。

グレースフルデグラデーションに関する2番目の質問については、開発者であるあなたが、あなたにとって重要なすべての状況でアプリが機能することを確認する必要があります。アプリをJavaScriptなしで動作させたい場合は、いつでも実際のHTMLフォームと送信ボタンを作成することができます。生成されたJavascriptリンクは、PUTを作成するリンクが本当に必要な場合のもう1つの方法です。繰り返しになりますが、これはRailsが素晴らしいと考えたものではありませんが、現在のすべてのブラウザー実装によって課せられた制限を回避する方法です。

于 2012-07-27T18:58:37.970 に答える
1

PUTおよびDELETEリクエストの問題は、HTMLフォームがそれをサポートしていないという事実です。ほとんどのフレームワークがそれを処理する方法は、POSTリクエストを介してそれらをトンネリングすることです。

「curl-XDELETEhttp://example.com/posts/1」を引き続き実行できますが、これは引き続き機能します。

ただし、RailsとRestについては多くの誤解があります。http://en.wikipedia.org/wiki/HATEOASおよびhttp://nicksda.apotomo.de/2010/12/rails-misapprehensions-rest-is-more-than-get-post-put-をご覧くださいおよび-削除/

于 2012-07-27T19:01:02.270 に答える