MVCおよびRESTful APIサービス
MVCは非常に単純です。モデル、コントローラー、ビューがあります。ウェブサイトを作成すると、「クライアントがRESTキーワードリクエストをサーバーに送信する->サーバーがコントローラーのアクションにリクエストされたURLを一致させる- >次に、データ収集/処理のためにモデルを呼び出し、結果を取得します->そして結果をHTMLページ（ビュー） 'としてクライアントに返します。
純粋なRESTful API Webサービスについて話している場合はどうなりますか？次に、フローは 'clientのようになりますRESTキーワードリクエストをサーバーに送信します->サーバーは、リクエストされたURLをコントローラーアクションに一致させます->呼び出しますデータ収集/処理のモデル、結果を取得し、結果をJSONでクライアントに返します。以前と同じですが、「ビュー」はありません。むしろ、生成されたJSONは「ビュー」と考えることができます。ある意味では、MVCのMC部分のみを使用しています。それはどのように行われるべきですか？それとも、他のより適切なパターンがありますか？ MVCの代わりにAPIのみのサービスの場合？
MVCは、オブジェクト指向システムがどのようにUIを持つことができるかに関係するSmalltalkの世界のパラダイムです。
初期のWebフレームワークは、一般的な概念（ビジネスロジック、制御ロジック、ビューロジックを分離する）を採用し、Webアプリケーションをどのように構造化するかに原則を適用していました。これ以前は、ドメインオブジェクト内にHTML生成コードのひどい混乱があったり、HTMLテンプレート内にビジネスロジックがあることは珍しくありませんでした（ごく初期のPHPを考えてください）。
問題は、Smalltalkの世界の元のMVCは、ほとんどのWebフレームワークのMVCとは実際には同じではないということです。 HTML出力は、SmalltalkがUI画面であると理解したという意味で、実際には「ビュー」ではありません。
それが、MVCを適切にフォローしているかどうかに夢中にならないための最初の理由です。ほとんど何もありません。厳密な分割ではなく、ガイドラインHTMLテンプレートにビジネスロジックが満載されていなければいいのではないでしょうか。
第二に、MVCはサーバー側のコードを構造化する方法にすぎません。 REST/HTTPとはまったく関係ありません。 RESTは、クライアントとサーバーの通信方法に関係しています。サーバーがクライアントに送信する表現が、テンプレートエンジンを使用して構築するのに多くの時間を要したHTMLテンプレートにあるかどうかは関係ありません。コントローラで1回の呼び出しであったJSONオブジェクト。
サーバーに「ビュー」レイヤーが必要だと思わない場合は、問題ありません。すべてのコントローラーが特定のオブジェクトでJSON解析呼び出しを呼び出してそのデータを返す場合でも、特定のHTTP要求を処理しているコントローラーからビジネスロジック（モデル）を分離することでメリットが得られます。
ビューは、アプリケーションのユーザー/クライアントによって解釈される可能性のある情報の表示を担当するレイヤーです（ユーザーが実際の人物である必要はありません）。 JSONはビューレイヤーに完全に有効な形式です。コンピューターはそれを理解しています。
ユーザーがアプリケーションのモデルに影響を与えるために使用できる情報をビューレイヤーが公開している限り、ビューの外観は問題ではなく、ビューであり、ユーザーとシステム間のミドルウェアとして機能するレイヤーです。 。
MVCは非常に単純です。
Martin Fowlerはおそらく これに同意しない ：
さまざまな場所でMVCについて読んでいるさまざまな人々が、さまざまなアイデアをMVCと表現しています。
次へ...
ウェブサイトを作成すると、「クライアントがRESTキーワードリクエストをサーバーに送信する->サーバーがコントローラーのアクションにリクエストされたURLを一致させる->モデルが呼び出されます>データ収集/処理の場合、結果を取得し->結果をHTMLページ（ビュー）としてクライアントに返します。
わかりました、これは少し複雑です
MVCは、それが何であれ、ユーザーインターフェイスを実装するためのアイデアのコレクションです。
RESTは、大規模なアプリケーションを構築するためのアーキテクチャ上の制約の集まりです。
ここで話しているのは、同じ制約のほとんどを使用して構築された巨大なドキュメント管理アプリケーションです。
2つの間で見られる類似点は、（選択してください）誤って属性付けされているか、表面的なものです。
RESTafarians[〜＃〜] hateoas [〜＃〜] について共通の理解があり、「アプリケーション状態のエンジンとしてのハイパーテキスト」であり、アラームが鳴るはずですhead-viewがstateのエンジンになるのはなぜですか？前提に疑問を投げかけ、追加の証拠を探す場合、2つの奇妙なことに気付くかもしれません。
まず、ディスクからHTMLをロードすることで、HTTPサーバーを完全に排除することができます。ブラウザはこれに完全に満足しており、ベースURLの変更から生じる可能性のある動作のいくつかのマイナーなバリエーションを許します。ビューは、通常、そのようにモデルおよびコントローラーから完全に切断されている場合、機能しません。
次に、最新のブラウザを注意深く観察すると、HTMLのビューが複数あることに気づくでしょう。ビューの複数のビューは本当に奇妙なアイデアのように見えますが、ユーザーのジェスチャーに応答する一連のテキストマークアップを含むメインプレゼンテーションがあり、生のHTMLを表示し、応答するこの「ソースビュー」があることは確かです。ユーザーのジェスチャー。カメはずっと下にいます！
もちろん、なぞなぞに対する答えは、HTMLはビューではないということです。ブラウザ内のウィジェットのコレクションはビューであり、それらはHTMLを読み取ることによって初期化されたDocument Object Modelと通信します。
言い換えると、HTMLは Roy T. Fielding が約束されているように、状態を表現したものです。
純粋なRESTful API Webサービスについて話している場合はどうなりますか？以前と同じですが、「ビュー」はありません
より正確には、以前と同じ：ビューはありません。 JSONは、HTMLと同様に、状態の表現であり、プロセスの境界を越えるのに適しています。
「DTO」または「メッセージ」を考えてください。そうすれば、誤解を招く可能性はかなり低くなります。
それはどのように行われるべきですか？
JSONをビューとして渡したり、ビューモデルとして使用してビューを構築したりしても、パターンに違反しません。
私が取り組んでいる現在のアプリケーションでも同じアーキテクチャを使用していますが、非常に優れています。いくつかの素晴らしいJSフレームワークと一緒に、いくつかの本当にレスポンシブなデザインを作成できます。
または、MVCの代わりにAPIのみのサービスに適した他のパターンはありますか？
正直なところ、わかりません。しかし、私はthink APIでMVCを使用するかどうかはそれほど重要ではないことを理解しています。便利なものは何でも使用してください。 Webサービスについて話すとき、考慮すべき多くの重要な側面があります（これはMVCに直接関連していません）。セキュリティ、一貫性、可用性など.