JSONデータではなくHTMLを返すエンドポイントの実際の何が問題になっていますか？
最初に学習を始めたときPHP（約5または6年前）） Ajax について学び、「フェーズ」を通過しました：
- サーバーがHTMLデータを返し、それを DOM's innerHTML内に配置します
- XMLなどのデータ転送フォーマット（そして「ああ、それが何のために使われるのか」と言います）とJSONについて学びます。
- JSONを返し、Vanilla JavaScriptコードを使用してUIを構築します
- あなたはjQueryに移動します
- API、ヘッダー、HTTPステータスコード、 [〜＃〜] rest [〜＃〜] 、 [〜＃〜] cors [〜＃〜] および- ブートストラップ
- [〜＃〜] spa [〜＃〜] 、およびフロントエンドフレームワーク（ React 、 Vue.js 、および AngularJS ）およびJSON API標準。
- エンタープライズレガシーコードを受け取り、検査すると、ステップ1で説明されていることを実行していることがわかります。
このレガシーコードベースで作業しているとき、HTMLを返すことができるとは考えていませんでした（つまり、私たちは今はプロです）。そのため、次のデータを返すJSONエンドポイントを探すのに苦労しました。 Ajax呼び出しが読み込まれます。 HTMLを返し、innerHTMLを使用してDOMに直接追加されると彼が言ったのは、私が「プログラマー」に尋ねたときでした。
もちろん、これを受け入れることは困難でした。これをJSONエンドポイントにリファクタリングする方法や、エンドポイントのユニットテストなどについて考え始めました。ただし、このコードベースにはテストがありません。 1つではありません。 20万行を超えています。もちろん、私の仕事の1つには、全体をテストするためのアプローチを提案することが含まれますが、現時点ではまだ取り組んでいません。
だから私はどこかで、疑問に思っています：テストがまったくないので、このJSONエンドポイントを作成する特別な理由はありません（「再利用可能」ではないため、文字どおり、その部分にのみ収まるデータを返します）アプリケーションですが、HTMLデータを返すため、これはすでに暗示されていると思います）。
これを行うことで何が正確に間違っているのですか？
JSONデータではなくHTMLを返すエンドポイントの実際の何が問題になっていますか？
何も、本当に。各アプリケーションには異なる要件があり、アプリケーションがSPAとして設計されていない可能性があります。
あなたが引用したこれらの美しいフレームワーク（Angular、Vue、Reactなど）は、開発時には利用できなかったか、組織で使用するための「承認された」エンタープライズ製品ではなかった可能性があります。
HTMLを返すエンドポイントはJavaScriptライブラリへの依存を減らし、DOMコードを作成するためにJSコードを解釈/実行する必要がないため、ユーザーのブラウザの負荷を減らします-HTMLはすでにそこにあります。要素を解析してレンダリングするだけです。もちろん、これは妥当な量のデータについて話していることを意味します。 10メガバイトのHTMLデータは妥当ではありません。
ただし、HTMLを返すことには何の問題もないため、JSON/XMLを使用しないことで失うものは、基本的にエンドポイントをAPIとして使用できる可能性です。そして、ここで最大の問題があります。それは本当にAPIである必要があるのでしょうか？
JSONとHTMLは、2つの異なる意味上の目的を満たします。
Webページにデータを入力する場合は、JSONを使用します。 Webページの一部からWebページを構築する場合は、HTMLを使用します。
彼らは同じように聞こえるかもしれませんが、まったく違います。 1つには、サーバーから返されたHTMLを使用してWebページの一部を構築しているとき、あなたは作業していますserver-side。 Webページにデータをバインドしているとき、あなたは作業しています- クライアント側
また、特定のページにしっかりとバインドしないように、HTMLに注意する必要があります。このように部分ページをレンダリングすることの要点は、部分ページをreusable、にすることであり、部分を具体的にしすぎると、他のページに構成されません。 JSONはWebページ構造ではなく単なるデータであるため、この問題はありません。
主な問題は、HTML構造を知っている必要のあるクライアントにサーバーを密結合することです。また、エンドポイントを新しい方法または新しいアプリケーションで再利用することがさらに困難になります。
プレーンデータを返してクライアントにレンダリングさせると、結合が減少し、柔軟性とテスト容易性が向上します。モックデータのクライアントでユニットテストを実行し、サーバーでユニットテストを実行して、目的のデータをテストできます。
少し後ろ向きだと思います。あなたは言う：
テストはまったくないため、このJSONエンドポイントを作成する特別な理由はありません
適切なエンドポイントを使用する理由は、あなたがcouldをテストするためです。何も書いていないのは、テストをしていないのが一番の理由だと思います。つまり、テストに適したロジックがある場合です。
20万行のコードはリファクタリングが多く、おそらくメンテナンスが困難です。いくつかのエンドポイントを分割してテストすることから始めるのがよいでしょう。
もう1つの理由は、サーバーをクライアントから分離することです。将来、アプリケーションのデザインやレイアウトが変更された場合でも、HTML出力よりも適切なデータ形式で作業する方が簡単です。理想的な世界では、クライアントを変更するだけで、サーバーにまったく触れる必要がありません。
Webページを作成するには、少なくとも3つの方法があります。
- ページ全体をサーバー側で生成します。
- サーバーとコード（JavaScript）から必要最低限のページを返し、ページにデータをフェッチしてHTMLクライアント側にレンダリングさせます。
- 部分的なページとコードを返し、ページにドロップできるHTMLの事前にレンダリングされたブロックをコードにフェッチさせます。
最初のものは大丈夫です。 2つ目も問題ありません。それが問題である最後のものです。
理由は簡単です。完全に切り離された部分へのHTMLページの構築dividedができました。問題はメンテナンスの問題です。これで、UIの詳細の管理を担当する2つのseparateエンティティーができました。したがって、CSSと他の同様の詳細を2つの別々の部分の間で同期させる必要があります。サイドバーの幅を変えましたか？すごい。サイドバーの幅に関する想定が保持されなくなったため、戻ってきたHTMLフラグメントによって水平スクロールが発生します。そのブロックの背景色を変更しましたか？すばらしいですね。HTMLフラグメントのフォントの色は、別の背景色を想定していて、誰かがそのエンドポイントをテストするのを忘れているため、干渉します。
重要なのは、1つの場所（つまり、プレゼンテーションロジック）に集中する必要のある知識を分割したことです。これにより、すべての要素を正しく組み合わせることが難しくなります。 JSON APIを使用することで、代わりにそのすべてのロジックをフロントエンドのみに保持することも、データをHTMLにレンダリングして最初からすべてをサーバー側のテンプレートに保持することもできます。プレゼンテーションのナレッジ/ロジックを1か所に保管することを目的としているため、一貫して、単一のプロセスの一部として管理できます。 HTML/CSS/JSは、多くの小さな断片に分解せずにそのままにしておくには十分に困難です。
JSON APIには、プレゼンテーションロジックから完全に独立してデータを利用できるという追加の利点もあります。これにより、モバイルアプリとWebページの両方など、複数のdifferentプレゼンターが同じデータを使用できます。特に、ブラウザーなしでデータを消費できるようにします（モバイルアプリや毎晩のcronジョブなど）。これらのコンシューマはHTMLを解析できない場合もあります。 （もちろん、これは、異なるコンシューマー間でデータが同じであるか、一方が他方のサブセットを使用できるかどうかに依存します。）ただし、この機能が必要かどうかは、プレゼンテーションの管理中に特定のアプリケーションの要件によって異なります。とにかくロジックが必要です。ただし、これを前もって実装すれば、将来の成長に備えることができます。
サーバーがHTMLフラグメントを返し、UIがそれを一部の要素の.innerHTMLに割り当てることには何の問題もないと思います。これは、私の意見では、非同期JavaScriptコードを開発する最も簡単な方法です。利点は、JavaScriptを使用してできる限り少ないことを行い、制御されたバックエンド環境でできるだけ多く行うことです。ブラウザーでのJavaScriptサポートはさまざまですが、バックエンドには常に同じバージョンのバックエンドコンポーネントがあるため、バックエンドでできるだけ多くのことを実行しても、バージョンの非互換性を最小限に抑えることができます。
さて、時々あなたは単なるHTMLフラグメント以上のものを望みます。たとえば、ステータスコードとHTMLフラグメントです。次に、statusCodeとHTMLの2つのメンバーを持つJSONオブジェクトを使用できます。その2番目のメンバーは、statusCodeを確認した後、ある要素の.innerHTMLに割り当てることができます。したがって、JSONの使用とinnerHTMLの使用は、決して代替の排他的なアプローチではありません。それらは一緒に使用できます。
JSONを使用することにより、複数の要素の.innerHTMLに割り当てられる同じ応答に複数のHTMLフラグメントを含めることもできます。
要約すると、.innerHTMLを使用してください。それはあなたのコードをできるだけ多くのブラウザバージョンと互換性があるようにします。さらに必要な場合は、JSONと.innerHTMLを一緒に使用してください。 XMLは避けてください。
何も問題はありません原則として。問題は、何を達成したいですか？
JSONはデータの送信に最適です。代わりにHTMLを送信し、クライアントがHTMLからデータを抽出することを期待する場合、それはごみです。
一方、HTMLとしてレンダリングされるHMTLを送信するためにwantを送信する場合は、HTMLを文字列にパックするのではなく、HTMLとして送信し、文字列をJSONに変換してJSONを送信します。 、反対側でデコードし、文字列を取得し、文字列からHTMLを抽出します。
そしてちょうど昨日、2つの項目を配列に入れ、配列をJSONに変換し、JSONを文字列に入れ、配列内に文字列を入れ、配列全体をJSONに変え、それをクライアントに送信してデコードしたコードに遭遇しましたJSONは、文字列を含む配列を取得し、文字列を取得し、文字列からJSONを抽出し、JSONをデコードし、2つの項目を持つ配列を取得しました。それをしないでください。
これはすべてAPIの目的に依存しますが、一般的に言っているのは懸念の分離のかなり強力な違反です。
最新のアプリケーションでは、APIコードがデータを担当し、クライアントコードがプレゼンテーションを担当する必要があります。
APIがHTMLを返す場合、データとプレゼンテーションを密接に結合しています。 APIがHTMLを返す場合、そのHTMLで（簡単に）できるのは、大きなページの一部として表示することだけです。別の角度から見ると、APIが有効なのはページにHTMLを提供することだけです。さらに、HTMLをクライアントコードとサーバーコードの両方に分散しました。これにより、メンテナンスが頭痛の種になることがあります。
APIがJSONまたはその他の形式の純粋なデータを返す場合、それははるかに便利になります。既存のアプリは引き続きそのデータを使用して、適切に表示できます。ただし、他のものがAPIを使用して同じデータにアクセスできます。繰り返しになりますが、メンテナンスも簡単です。すべてのHTMLが1か所にあるため、サイト全体のスタイルを変更したい場合は、APIを変更する必要はありません。
HTMLは特定のデザインと使用に関連付けられています。
HTMLでは、ページレイアウトを変更したい場合は、サーバー呼び出しによってHTMLが生成される方法を変更する必要があります。通常、これにはバックエンドプログラマが必要です。これで、バックエンドプログラマーがいます。定義上、これらのプログラマーはこれらの更新を処理するのに最適なHTMLライターではありません。
JSONでは、ページレイアウトが変更された場合、既存のJSONサーバー呼び出しを必ずしも変更する必要はありません。代わりに、フロントエンドの開発者、またはデザイナーでさえ、テンプレートを更新して、同じ基本データから必要なさまざまなHTMLを生成します。
さらに、JSONは他のサービスの基礎になる可能性があります。同じ基本データをさまざまな方法で表示する必要があるさまざまな役割がある場合があります。たとえば、注文ページに製品に関するデータを表示する顧客のWebサイトと、同じデータを非常に異なるレイアウトで表示する営業担当の内部販売ページがあり、おそらく一般的な顧客には入手できない他の情報もあるとします。 JSONでは、同じサーバー呼び出しを両方のビューで使用できます。
最後に、JSONはより適切にスケーリングできます。近年、クライアントサイドのjavascriptフレームワークが過剰になりました。実際に一歩下がって、私たちが使用しているjavascriptと、それがブラウザーのパフォーマンスにどのように影響するかを考え始めるときがきたと思います...特にモバイルデバイスでは。つまり、単一のサーバーではなく、サーバーファームまたはクラスターを必要とするのに十分な大きさのサイトを実行している場合、JSONはより適切にスケーリングできます。ユーザーはブラウザーでの処理時間を無料で提供します。これを利用すると、大規模な展開でサーバーの負荷を軽減できます。また、JSONは使用する帯域幅が少ないため、繰り返しになります十分な大きさの場合で適切に使用すると、JSONの方がかなり安価です。もちろん、40KBのライブラリにフィードして2KBのデータを7KBのhtmlに解析する場合、スケーリングも悪化する可能性があります。繰り返しますが、何をしているのかを知っておく必要があります。しかし、JSONがpotentialを使用してパフォーマンスとコストを改善できます。
要件を満たしていれば、そのようなエンドポイントに問題はありません。既知のコンシューマーが効果的に解析できるHTMLを吐き出す必要がある場合は、どうでしょうか。
問題は、一般的なケースでは、エンドポイントが整形式で標準のパーサーによって効果的に解析可能なペイロードを吐き出してほしいということです。そして、効果的に解析可能、つまり、宣言的に解析可能です。
クライアントがペイロードを読み取り、ループとifステートメントでペイロードから情報ビットをこじ開けるように強制されている場合、効果的に解析することはできません。そしてHTMLは、その方法であるので、それ自体が整形式である必要がないという点で非常に許されています。
さて、もしあなたのhtmlがxml準拠であることを確認すれば、あなたは金持ちです。
そうは言っても、これには重大な問題があります。
HTMLを返すエンドポイントは、JavaScriptライブラリへの依存を減らし、DOMコードを作成するためにJSコードを解釈/実行する必要がないため、ユーザーブラウザの負荷を減らします-HTMLはすでにそこにあります。要素を解析してレンダリングするだけです。もちろん、これは妥当な量のデータについて話していることを意味します。 10メガバイトのHTMLデータは妥当ではありません。
どんなにカットしても、それは悪い考えです。何十年にもわたる産業での経験から、一般的には、データ（またはモデル）をその表示（またはビュー）から分離することが推奨されます。
ここでは、高速なJSコード実行のために2つを融合しています。そして、それはミクロの最適化です。
非常に些細なシステムを除いて、これを良いアイデアとして見たことはありません。
私のアドバイス？しないでください。 HC SVNT DRACONES、YMMVなど.
正誤を分類するのは難しい。 IMO、私が尋ねる質問は次のとおりです： "should it"、または "less it with less？"。
すべてのエンドポイントは、できるだけ少ないコンテンツで通信するように努める必要があります。信号対雑音比は通常、HTTPコード<JSON <XHTMLです。ほとんどの状況では、最もノイズの少ないプロトコルを選択することをお勧めします。
最近のブラウザーでは問題ないので、クライアントブラウザーのロードに関する点で@machadoが異なります。それらのほとんどは、HTTPコードとJSON応答をかなりうまく処理するために装備されています。現時点ではテストはありませんが、ノイズの少ないプロトコルを長期間維持する方が、その上のプロトコルよりも安価になります。
JSONは、構造化データの単なるテキスト表示です。クライアントはデータを処理するために当然パーサーが必要ですが、事実上すべての言語にはJSONパーサー関数があります。 HTMLパーサーを使用するよりも、JSONパーサーを使用する方がはるかに効率的です。フットプリントはほとんど必要ありません。 HTMLパーサーではそうではありません。
PHPでは、json_encode($data)を使用するだけで、反対側のクライアントがそれを解析します。また、WebサービスからJSONデータをフェッチするときは、$data=json_decode($response)を使用するだけで、変数の場合と同じようにデータの使用方法を決定できます。
モバイルデバイス向けのアプリを開発するとしますが、モバイルアプリがデータを解析するためにWebブラウザーをほとんど使用しないのに、なぜHTML形式が必要なのでしょうか。多くのモバイルアプリは、JSON（最も一般的な形式）を使用してデータを交換します。
多くの場合、携帯電話は従量制プランを採用していることを考えると、JSONよりもはるかに多くの帯域幅を必要とするHTMLを使用したいのはなぜですか？
HTMLの語彙が制限されており、JSONでデータを定義できるのに、なぜHMTLを使用するのですか？ {"person_name":"Jeff Doe"}は、データを定義するのではなく、HTMLパーサーの構造を定義するだけなので、HTMLがそのデータについて提供できるよりも有益です。
JSONはHTTPとは関係ありません。 JSONをファイルに入れることができます。構成に使用できます。 ComposerはJSONを使用します。これを使用して、単純な変数をファイルに保存することもできます。