Ajax通信でデータをフロントに渡す際、JSON形式にこだわる理由はあるのでしょうか？

表題について、以下のような場合、htmlで返すのが適切だと思うのですがいかがでしょうか？

###実現したい仕様
初回アクセス時のレスポンスが以下のようなものとします。

<html>
<head></head>
<body>
	<ul>
		<li>データ1</li>
		<li>データ2</li>
		<li>データ3</li>
	</ul>
</body>
</html>

その後、ajax通信によりページ遷移無しでデータ4以降が読み込まれます。

<html>
<head></head>
<body>
	<ul>
		<li>ツイート1</li>
		<li>ツイート2</li>
		<li>ツイート3</li>
		<li>ツイート4</li>
		<li>ツイート5</li>
		<li>ツイート6</li>
		...
	</ul>
</body>
</html>

###上記を実現する方法A
jsonで受け取り、jsでhtmlに形成してappend。

$.ajax({
	url: 'hoge.php',
	dataType: 'json'
}).done(function(json) {
	// json : ["データ4","データ5","データ6"]
	json.forEach(function(e) {
		$('ul').append($('<li>').append(e));
	});
});

###上記を実現する方法B
サーバーでhtmlに形成し、jsはappendするだけ。

$.ajax({
	url: 'hoge.php',
	dataType: 'html'
}).done(function(html) {
	// html : <li>データ4</li><li>データ5</li><li>データ6</li>
	$('ul').append(html);
});

###Bの方が良いのでは？
上記2つのうち、フロントの方に求められるレスポンスは圧倒的にAのjson形式が多いように思います。

初回レスポンスは当然htmlなのに、ajaxで追加データ、となった途端にjson形式が好まれるのは何故でしょうか？

今回の場合、Aだとデータをhtml化する処理がサーバーにもフロントにも作られることになってしまいイマイチな気がします。

jsonの方がデータ量が少ないとしても、その分jsにデータをhtml化する処理を追加しなければいけませんし、よほど大きなデータを頻繁にやりとりするサイトでなければこの点で優位になるようには思えません。

また、jsonなら、<li>で囲む以外にもフロント次第で<div>にしたりと色々な場面へ展開できますが、パターンが限られているなら、GETパラメータなりでhoge.php内を分岐させればいいと思います。

###もしjsでhtml化したい場合

最近の流行りでもありますが、データ1~3含め全てをjsがhtml化するとします。

しかし、これを実現するために、初回レスポンスの直後に再びajax通信でサーバへjsonデータをリクエストしているのを見かけますが、無駄に通信回数が増えているように感じます。

初回レスポンスの時点で初期表示に必要なjson文字列をhtml内にインクルードして返すのではだめなのでしょうか？

<script>var data = ["データ1","データ2","データ3"];</script>

###質問のまとめ

長くなって申し訳ありません。まとめると以下2点についてご意見を頂きたいです。

今回の例の場合、Bの方法のようにhtml形式でやりとりするのが適切な気がするのですがいかがでしょうか？
初回表示の3件もjsonで受け取るにしても、わざわざajax通信せずにhtml内にインクルードすればいいと思うのですがいかがでしょうか？

よろしくお願いたします。

行動規範の内容に同意します

回答6件

ベストアンサー

JSONにする理由はもちろんデータ量がHTMLと比べて少なくなるというのもありますが、

例えばリストの表示を<ul>から<table>へ変更したりする場合、サーバー側で行っているHTML生成処理も変更が必要となります。HTMLで返すとなると、このようにクライアントとサーバーの依存度が高くなってしまいメンテナンス性が悪くなってしまいます。

あと、初回表示のデータはHTMLにインクルードするというのはリクエスト1回で済むためとても有用です。
ここ最近は、Vue.jsやReact.jsといったフレームワークを使用するのが主流となってきてますが、
初回アクセスの時のみサーバーサイドレンダリングをおこなうという方法により、ページ表示速度を早くするということもとられています。
(私は、サーバーサイドレンダリングではなく初回データのインクルードのほうがいいと思うんですけどね)

投稿2017/03/23 04:25

turbgraphics200

総合スコア4267

実装というよりは設計とか規模の違いだと思います。

汎用性の確保。そのほかの画面で使うことはないか。
X画面では縦たけど。Y画面では横に表示したいとか。Z画面ではプルダウンにしたいとか。
Bの方法だと3つのAPIが必要になって工数3倍ですよね。テストも作って面倒。
Aの方法だとプルダウン用のAPI作って使いまわしが効く。

責任の切り分け。フロントとバッグで違うエンジニアが実装する場合の考慮。
画面側の設計をバックのエンジニアが気にしないといけない。

あとはAPP全体の統一性として、
このAPIはJSONなのにあのAPIはhtmlで返ってくるみたいな面倒なことになるので
JSON統一になっているのかと思います。

初期表示についても、
初期表示用のデータ取得処理を専用で書くくらいなら、
データ取得のAPIは必要なんだから、それを利用して初期表示もしたらいいんじゃないかと。。。
プログラマの怠慢かもしれませんが。

個人的に実装して作ったら終りくらいの感じであればBでも全然いいですが、
継続的に運用していくとか誰かに引き継ぐとかを考えるとAのほうがいいと思います。

投稿2017/03/23 05:10

szk.

総合スコア1400

みなさま、ご回答有り難うございました。
それぞれ場合による優位性などを詳しく説明していただき参考になりました。

投稿2017/03/23 05:27

n_kitamura

総合スコア17

サーバー1台、ブラウザ1つならどちらでもいいと思います。
しかし、アクセスしてくるブラウザの数が数千、数万になった時に、データ加工処理がサーバーを圧迫してきそうですね。

投稿2017/03/23 05:14

yona

総合スコア18155

素人なので的外れな回答でしたらすみません。

前者について、ケースによると思いますが、innerHTMLよりもcreateElement系の方が速かった（参考）と思いますので、クライアントでの速度はJSON有利ではないでしょうか。サーバ側の処理についてはよく分かりませんが、構造体をJSONパースするのと、HTMLを作成するのでそれほどコストは変わらない気がします。

後者について、おっしゃる通りかと思いますが、動的データ部分のコストによりますが、とりあえずHTMLを静的に出力した方が、表示される時間が短縮され体感速度が向上するような気がします。「初回表示を持たせるか否か」というよりも、「コストの高い処理を非同期化する」と考えるべきで、初回表示処理が軽いなら持たせた方がいい、ということになるのではないかと思います。

投稿2017/03/23 04:32

編集2017/03/23 04:59