コメントでの私の主張は、MVCパラダイムのRESTfulアーキテクチャの目的を、主に「すべてのAJAX呼び出しが1つのコントローラーに送信される」ことに焦点を当てて無効にしているというものでした。それでは、これを使用可能なものに分解してから、理由/方法の理解を再構築しましょう。
RESTは単にREpresentationalStateTransferを意味しますが、RESTまたはRESTfulと言うときはそれを意味しません。つまり、各URLがリソースのタイプを表すことを意図しており、動詞を使用して各リクエストで何を行っているかを示します。したがって、「GET」、「POST」、「PUT」などにはすべて目的があり、その目的を使用して、個々のリソースとの対話方法を決定します。
それでは、それを視野に入れて、それを使って何かをしましょう。HRアプリケーションを検討してください(これは、人々が採用する簡単なアプリケーションの1つです)。人と部門があります。部門には、ID、名前、およびマネージャー(個人)があります。人々は、ID、名前、マネージャー(マネージャーがいないことを示すために、システムでは-1、または人のID)、および電話番号を持っています。
HTTP GET http://server.domain/app/Personを実行すると、すべての人のディレクトリが取得され、名前とIDが示されます。
[ {Name: "Cole Brand", ID: 1}, {Name: "user341180", ID: 2} ]
HTTP GET http://server.domain/app/Person/1を取得すると、
{ Name: "Cole Brand", ID: 1, Manager: -1, "Phone Number": "222-555-1234" }
HTTP GET http://server.domain/app/Person/2を取得すると、
{ Name: "user341180", ID: 2, Manager: 1, "Phone Number": "222-555-6789" }
そして、完全を期すために、部門のリストは次のとおりです。
HTTP GET http://server.domain/app/Department/
{ Name: "HR", Manager: 1 }
たとえば、従業員は確かに部門で働いているので、私の例は少し乾燥していますが、プロファイルによってそれらを関連付けていません。確かにデータベースはそれを追跡しますが、ここにはありません。これは簡単な例です。
したがって、これからHTMLが返されないことがわかります。それに戻ります。
次のパートでは、HTTPGETを使い続けていることに注意してください。HTTP POSTを使用した場合はどうなりますか?これは、渡したものが何であれ、そのデータを上書きすることを意味します。簡単な例を挙げましょう。
HTTP POST http://server.domain/app/Person/2
send this data in the post body { Manager: -1, "Phone Number": "222-555-0089" }
get nothing in response (we could return the object, but my API doesn't for whatever reason, call it a specification deficiency)
HTTP GET http://server.domain/app/Person/2を実行すると、次のようになります。
{ Name: "user341180", ID: 2, Manager: -1, "Phone Number": "222-555-0089" }
HTTPPOSTを使用してレコードを更新した方法をご覧ください。これがRESTfulメソッドの使用方法であり、動詞を使用してアクションを示します。
では、サーバーとの通信に他に何を使用できるでしょうか。RESTfulメソッドがWebページとデータの両方を返すようにしたいが、GETの場合はどうなりますか?HTTPヘッダー(おそらくXヘッダー?)を使用してデータ呼び出しを行うことを指定できるため、デフォルトではHTTPGEThttp://server.domain/app/Person/1にリクエストを送信します。 Webページを取得します。その例(Webページを提供するREST応答)が必要な場合は、現在表示しているページを確認してください。https://stackoverflow.com/questions/11061912/
<-実際にはMVCのRESTful原則によって提供されます(ただし、システムのセットアップ方法ではないため、この方法でJSONを提供するとは思いません)。
だから私はおそらくあなた方全員を混乱させているでしょう、私はただRESTをレビューしたいと思いました、そして私達が今日MVCの目的のためにそれをどのように使用するか。その一部、 http://server.domain/app/Personを行う部分をもう一度見てみましょう。
MVCの用語では、アプリにPersonコントローラーがあることを意味します。Personコントローラーに対して行われたすべての要求は、最初に動詞タイプに基づいてルーティングされ、次に追加のパラメーターに基づいてルーティングされます。たとえば、この回答を送信すると、に投稿されhttps://stackoverflow.com/questions/11061912/answer/submit
ます。したがって、コントローラーは、「投稿ID」(つまり、回答が属する親を知っている)を受け取ることを期待していることを認識し、「回答」は、回答を追加していることを通知し、「送信」して、私が何であるかを認識します。やっています。私が編集している場合、それは回答/送信ではなく編集-送信になります。
わかりました、それで私は物事を混乱させているように感じます、そしてあなたがノードと一般のMVCに関する私の答えを読んだかどうかわかりません:モデルはどのようにビューに結び付けられていますか?ただし、明確にしておきます。コントローラーは、入力を受け取り、それを適切なモデルに送信してから、ビュー(HTML、JSON、XML、プレーンテキストなど)をレンダリングするためのルーティングデバイスです。ビューをレンダリングする必要がないことに注意してください(HTTP POSTで何も返さなかった私のくだらないAPIを覚えていますか?)。
だから今、私は以前の私の応答で得ようとしていたことのポイントに到達しましたが、それはまだ十分に明確ではありません。「適切なリソース」(この投稿/ question /の場合)からメソッドを移動すると、1つのURLルートが1つのリソースであるという考えを破ることになります。ああ、私はこれをすべて台無しにしましたね?
RESTの原則では、各URLルートは1つのリソースです。そのリソースから、データの一部に基づいて特定のビューをレンダリングしたり、特定の動詞を使用してデータを追加/変更したり、それが自分のスタイルであればフラップジャックを作成したりすることができます。ただし、すべてのPersonは常にhttp://server.domain/app/Personにあり、「一部のPersonコマンドはhttp://server.domain/app/Personにあり、一部のPersonコマンドはhttp://serverにあります。 domain / app / Department "それなら、あなたはただ腕を空中に投げ上げて、「人々の行動を見つけるためにどこにいるのかをどうやって知るのですか?!?!」
つまり、一言で言えば、同じリソースタイプの1つのコントローラー(ビューのレンダリング)のデータにアクセスするためのいくつかのメソッドと、別のコントローラー(JSON)のデータにアクセスするためのいくつかのメソッドを配置したくない理由です。
すべてのブレインダンプを投稿に入れたので、どの部分にあいまいですか?投稿を自由に編集して、適切と思われるものを挿入して**what do you mean here?**
ください。**you seem to be jumping around on this point a lot**