MVCは非常に単純です。モデル、コントローラー、ビューがあります。Webサイトを作成すると、クライアントがRESTキーワード要求をサーバーに送信するときにすべてがまとめられます->サーバーは要求されたURLをコントローラーアクションに一致させます->データ収集/処理のためにモデルを呼び出し、結果を取得します->そして、結果をHTMLページ（ビュー）としてクライアントに返します。
純粋なRESTful API Webサービスについて話している場合はどうなりますか？次に、クライアントは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テンプレートにビジネスロジックが満載されていないのであれば、Heyのガイドラインを参考にしてください。
第二に、MVCはサーバー側のコードを構造化する方法の1つにすぎません。REST / HTTPとはまったく関係ありません。RESTは、クライアントとサーバーの通信方法に関係しています。サーバーがクライアントに送信する表現が、テンプレートエンジンで構築するのに多くの時間を要したHTMLテンプレートであるか、コントローラーで1回の呼び出しであったJSONオブジェクトであるかは関係ありません。
サーバーに「ビュー」レイヤーが必要だと思わない場合は、問題ありません。すべてのコントローラーが特定のオブジェクトでJSON解析呼び出しを呼び出してそのデータを返す場合でも、特定のHTTP要求を処理しているコントローラーからビジネスロジック（モデル）を分離することでメリットが得られます。
MVCは非常に単純です。
さまざまな場所でMVCについて読んでいるさまざまな人々は、そこからさまざまなアイデアを取り入れ、これらを「MVC」と表現しています。
次へ...
Webサイトを作成すると、「クライアントがRESTキーワード要求をサーバーに送信する->サーバーが要求されたURLをコントローラーアクションに一致させる->データ収集/処理のためにモデルを呼び出して結果を取得するため、すべてがまとめられます。 ->そして、結果をHTMLページ（ビュー）としてクライアントに返します。
わかりました、これは少し複雑です
MVCは、それが何であれ、ユーザーインターフェイスを実装するためのアイデアのコレクションです。
RESTは、大規模なアプリケーションを構築するためのアーキテクチャ上の制約のコレクションです。
ここで話しているのは、同じ制約のほとんどを使用して構築された巨大なドキュメント管理アプリケーションです。
2つの間で見られる類似性は、（あなたが選んだ方がいい）誤った属性であるか、表面的なものです。
RESTafarianはHATEOASを一般的に理解しており、「アプリケーション状態のエンジンとしてのハイパーテキスト」であり、頭の中でアラームが鳴るはずです。なぜビューが状態のエンジンになるのでしょうか。前提に疑問を投げかけ、追加の証拠を探す場合、2つの奇妙なことに気づくかもしれません。
まず、ディスクからHTMLをロードすることにより、HTTPサーバーを完全に排除することができます。ブラウザはこれに完全に満足しており、ベースURLの変更から生じる可能性のある動作のいくつかのマイナーなバリエーションを許します。ビューは、通常、そのようにモデルとコントローラーから完全に切断されていると機能しません。
次に、最新のブラウザを注意深く観察すると、HTMLのビューが複数あることに気づくでしょう。ビューの複数のビューは本当に奇妙なアイデアのように見えますが、ユーザーのジェスチャーに応答する一連のテキストマークアップを含むメインプレゼンテーションがあり、生のHTMLを表示し、応答するこの「ソースビュー」があることは確かです。ユーザーのジェスチャー。カメはずっと下にいます！
もちろん、なぞなぞに対する答えは、HTMLはビューではないということです。ブラウザ内のウィジェットのコレクションはビューであり、HTMLを読み取ることによって初期化されたDocument Object Modelと通信します。
言い換えれば、HTMLは、ロイT.フィールディングが約束したように、状態の表現です。
純粋なRESTful API Webサービスについて話している場合はどうなりますか？以前と同じですが、「ビュー」はありません
より正確には、以前と同じ：ビューはありません。JSONは、HTMLと同様に、状態の表現であり、プロセスの境界を越えるのに適しています。
「DTO」または「メッセージ」を考えてください。そうすれば、誤解を招く可能性がはるかに低くなります。
それはどのように行われるべきですか？
JSONをビューとして渡す、またはビューモデルとして使用してビューを構築しても、パターンに違反しません。
私が取り組んでいる現在のアプリケーションでも同じアーキテクチャを使用していますが、非常に優れています。素敵なJSフレームワークと組み合わせることで、本当にレスポンシブなデザインを作成できます。
または、MVCの代わりにAPIのみのサービスに適した他のパターンはありますか？
正直、わからない。しかし、APIでMVCを使用するかどうかはそれほど重要ではないと思います。便利なものは何でも使用してください。Webサービスについて話すとき、考慮すべき多くの重要な側面（MVCに直接関係しない）があります。たとえば、セキュリティ、一貫性、可用性などです。