すべての新しいWebプロジェクトは、xml / json結果セットに基づいてバックエンドを構築する必要がありますか？
新しいSaasプロジェクトを構築している場合、すべてのバックエンドサービスがxml/jsonを返すことから始めるのは理にかなっていますか？
最近では、Webデバイスとモバイルデバイスの両方を構築する必要があり、最初からxmlとjsonを返すように構築されたバックエンドがあるため、モバイルに移行する準備ができています（すべてのサービスにビジネスロジックがあるため、何でも繰り返します）。
これでWebはMVCになるため、コントローラーはリクエストをサービスバックエンドにルーティングし、jsonまたはxmlをhtmlに変換します。
明らかな欠点は、バックエンドを作成する必要があり、次にバックエンドを呼び出す別のWebプロジェクトを作成する必要があることです。ただし、懸念事項を分離する必要があり、コントローラー/ビューレイヤーのビジネスロジックをリークしないため、これも好意的になります。
考え？
質問に対するYESまたはNOの回答はありません。第2レベルの間接参照をxml/json APIの形式で導入するかどうかの決定は、プロジェクトで何をしようとしているかによって異なります。
ご指摘のとおり、最近では多くのプロジェクトがモバイル化されていますが、Webインターフェースのカスタマイズされたバージョンを提示するだけでモバイル機能を提供する簡単な方法はありませんか？私はこれに答えることはできませんが、おそらく答えることができます。
あなたがあなた自身に尋ねるかもしれない他の質問は以下を含みます：私のアプリケーションにクライアントを書くことをいとわない他のものはありますか？答えが「はい」の場合は、xml/json APIよりも良い方法かもしれません。
編集：PS-ビジネスロジックをMVCから分離しても、同じように重要です。 APIはそれを強制しますが、2番目のレベルのカプセル化がなくても問題なく実行できるはずです。
アプリケーションによって異なります。多くの企業は単にWeb APIサービスレイヤーを必要とせず、標準のMVCプラクティスを使用して、適切に設計されたシンコントローラーからレンダリングされたページを提供できます。これは、APIにヒットするメンテナンス不可能なjavascript（ほとんどの場合）で完全に記述されたビューレイヤーのようなものより、作成がはるかに速く、メンテナンスが簡単です。
ほとんどのフレームワークは、ビューが同じアプリケーションでレンダリングされることを想定しているので、その想定に立ち向かい、多くの「無料」機能を失うことになります。ビジネスロジックはどちらの方法でもリークする可能性があるため、追加の抽象化レイヤーが何かをもたらすかどうかが問題になります。
番号。
XML/JSONは単なるデータ形式です。
ビジネスロジックとプレゼンテーションを明確に分離することは理にかなっています（小さなプロジェクトでない限り）。アプリケーション内の操作を公開するものであり、プレゼンテーションの問題で汚染されていない（つまり、HTTPリクエストではなくプリミティブ、ビジネスロジックオブジェクト、GUIイベントなどを取る）プロシージャ/関数/メソッドがある場合、それはかなり適切です。 XML、JSONなど、さまざまな方法で簡単に公開できます。もちろん、適切なプレゼンテーションレイヤーから直接呼び出すこともできます。
「ハード」な分離を強制する必要はありません。実際にはそれほど多くの規律は必要ありません。他の理由（たとえば、異なるチームなど）のために個別のプロジェクトが必要な場合でも、バックエンドを可能であれば、サービスとしてではなく「ライブラリ」-直接的なメソッド呼び出しは、あらゆる意味でオーバーヘッドが少なく、非常に望ましいです。
はい、それは本当に意味があり、優れたアーキテクチャだと思います。 JSON/XMLをサーバーから透過的にクライアントに返すのはとても簡単です-追加のレイヤーを書く必要はありません。 JavaScriptクライアントは簡単にJSONを使用します。あなたは懸念を明確に分離しています。必要に応じて、コンパイル時の検証のために共有モデルからコードを生成できます。そしてもちろん、追加のクライアントのサポートに関する質問で述べた柔軟性があります。モバイル。バックエンドテクノロジーも変化する可能性があることを忘れないでください。私は最後の仕事で.NETバックエンドをJava/spring/Tomcatバックエンドに交換しました。
おそらくyes、あなたのclients are going to consume Restful HTTP services.
Json/xml形式のデータ交換でHTTPサービスを広範囲に使用するWeb /モバイルアプリケーションの傾向が高まっています。したがって、.NETプラットフォームで開発している場合、開発を容易にする ASP.NET Web API テクノロジーがあり、箱から出して最も基本的な機能を提供します。
あなたがdeveloping for different platform、まだhttpサービスと言及されたデータ形式のデータ交換タイプが重要な役割を果たし始めており、その方向に進むことがますます重要になっています。
いいえ、すべてのビジネスサービスを「ブラインドで」公開しないでください。例外として、アプリに100％スマートクライアントのフロントエンドがある場合（つまり、動的Htmlがサーバーからレンダリングされない場合にのみ考慮する）が例外です。
根拠は：
- これにより、追加のTCP/IPスタック「ホップ」が原因で、コントローラーレンダリング画面のパフォーマンスが不必要に遅くなります
- 攻撃者にとってより大きな表面領域を作成します-実際に使用していないサービスをロックダウンするのを忘れることがあります。
- サービスの公開は、正式な方法で行う必要があります（たとえば、JSON /ブラウザークライアントのコントローラーをオフにするか、Webサービスなどの統合サービスの正式なセット）。これを行わないと、企業では、知らないサービスの消費者がたくさんいることに気付くでしょう。
- 多くの場合（とにかく.NETで）、Ajaxサービスはビューに密接に結合されていることが多いため、JSONサービスをブラウザーに公開することは、MVCコントローラーから行うのが最善です。これは、統合サービス（SOAP/WSE）など）を他のシステムに公開するための適切な場所ではありません。
つまり、ロジックをビューとコントローラーから「バックエンドレイヤー」に移動することは適切ですが、コントローラーとバックエンドの間の結合は必ずしもWebサービスの境界を越えているとは限りません。
Backbone.jsのようなJavaScriptクライアント側のUIレンダリングフレームワークや、pjaxのような他のさまざまなトリックの台頭により、このオプションはますます人気が高まっています。
ビジネスロジックをプレゼンテーションの問題から分離することは常に良い考えです。
予算/時間に応じて、パブリックAPIをスキップし（OAUTH自体は大きな時間のシンクです））、json結果セットを使用するためのコントローラーとビューを構築しますあなたのアプリケーション固有のコードによって返されます。私はしばらくの間このアプローチを進めていますが、予想よりも早く返済されます。
あなたは読みたいかもしれません The Clean Architecture 、Robert Martin（UncleBob）からの素晴らしいブログ投稿。そこにいくつかの良いアドバイスがあります。
Webアプリケーションで画面を再利用しなければならないたびに、新しい目的には少し異なるクエリと異なるビジネスロジックが必要でした。再利用のアイデアは素晴らしいですが、私がプロのWebアプリケーション開発者である12年間、それがそのように機能するのを見たことはありません。あなたのマイレージは異なる場合があります。