it-swarm.com.de

Was ist eigentlich falsch an einem Endpunkt, der HTML anstelle von JSON-Daten zurückgibt?

Als ich anfing zu lernen PHP (vor ungefähr 5 oder 6 Jahren), lernte ich Ajax und ging "die Phasen" durch:

  1. Ihr Server gibt HTML-Daten zurück und Sie fügen sie in ein DOM's innerHTML ein
  2. Sie lernen Datenübertragungsformate wie XML kennen (und sagen "oooh, das ist es, wofür es verwendet wird") und dann JSON.
  3. Sie geben JSON zurück und erstellen Ihre Benutzeroberfläche mit Vanilla JavaScript-Code
  4. Sie wechseln zu jQuery
  5. Sie erfahren mehr über APIs, Header, HTTP-Statuscodes, REST , CORS und - Bootstrap
  6. Sie lernen SPA und Frontend-Frameworks ( React , Vue.js und AngularJS ) und der JSON-API-Standard.
  7. Sie erhalten einen Unternehmens-Legacy-Code und stellen bei der Überprüfung fest, dass dieser die in Schritt 1 beschriebenen Schritte ausführt.

Als ich mit dieser alten Codebasis arbeitete, dachte ich nicht einmal daran, dass sie HTML zurückgeben könnte (ich meine, wir sind jetzt Profis, oder?), Daher fiel es mir schwer, nach dem JSON-Endpunkt zu suchen, der die Daten zurückgibt, die Die Ajax-Aufrufe werden ausgefüllt. Erst als ich "den Programmierer" fragte, sagte er mir, dass HTML zurückgegeben und mit innerHTML direkt an das DOM angehängt werde.

Das war natürlich schwer zu akzeptieren. Ich begann über Möglichkeiten nachzudenken, dies in JSON-Endpunkte umzugestalten, über Unit-Tests der Endpunkte nachzudenken und so weiter. Diese Codebasis hat jedoch keine Tests. Nicht ein einziger. Und es sind über 200.000 Zeilen. Natürlich gehört es zu meinen Aufgaben, Ansätze zum Testen des Ganzen vorzuschlagen, aber im Moment gehen wir das noch nicht an.

Ich frage mich also nirgends in einer Ecke: Wenn wir überhaupt keine Tests haben, haben wir keinen besonderen Grund, diesen JSON-Endpunkt zu erstellen (da er nicht "wiederverwendbar" ist: Er gibt buchstäblich Daten zurück, die nur auf diesen Teil von passen Anwendung, aber ich denke, dies wurde bereits impliziert, da es ... HTML-Daten zurückgibt).

Was genau ist daran falsch?

79

Was ist eigentlich falsch an einem Endpunkt, der HTML anstelle von JSON-Daten zurückgibt?

Nichts wirklich. Jede Anwendung hat unterschiedliche Anforderungen, und es kann sein, dass Ihre Anwendung nicht als SPA konzipiert wurde.

Es kann sein, dass diese schönen Frameworks, die Sie zitiert haben (Angular, Vue, React usw.), zur Entwicklungszeit nicht verfügbar waren oder keine "genehmigten" Enterprise-Dinger für Ihre Organisation waren.

Ich werde Ihnen Folgendes sagen: Ein Endpunkt, der HTML zurückgibt, verringert Ihre Abhängigkeit von JavaScript-Bibliotheken und verringert die Belastung des Browsers des Benutzers, da er zum Erstellen von DOM-Objekten keinen JS-Code interpretieren/ausführen muss - der HTML-Code ist bereits vorhanden. Es geht nur darum, die Elemente zu analysieren und zu rendern. Dies bedeutet natürlich, dass es sich um eine angemessene Datenmenge handelt. 10 Megabyte HTML-Daten sind nicht sinnvoll.

Da es jedoch nichts Falsches gibt, HTML zurückzugeben, verlieren Sie im Grunde genommen die Möglichkeit, Ihren Endpunkt als API zu verwenden, wenn Sie JSON/XML nicht verwenden. Und hier liegt die größte Frage: Muss es wirklich eine API sein?

Verwandte: Ist es in Ordnung, HTML von einer JSON-API zurückzugeben?

115
Machado

JSON und HTML erfüllen zwei unterschiedliche semantische Zwecke.

Wenn Sie eine Webseite mit Daten füllen, verwenden Sie JSON. Wenn Sie eine Webseite aus Teilen von Webseiten erstellen, verwenden Sie HTML.

Sie mögen irgendwie so klingen, als wären sie dasselbe, aber sie sind es überhaupt nicht. Zum einen arbeiten Sie, wenn Sie einen Teil einer Webseite mit vom Server zurückgegebenem HTML erstellen, serverseitig Wenn Sie Daten an eine Webseite binden, arbeiten Sie - clientseitig.

Außerdem müssen Sie mit HTML vorsichtig sein, um nicht fest an eine bestimmte Seite gebunden zu sein. Der springende Punkt beim Rendern von Teilseiten auf diese Weise ist, dass die Teilseiten wiederverwendbar, sind. Wenn Sie das Teil zu spezifisch machen, wird es nicht zu anderen Seiten zusammengesetzt. JSON hat dieses Problem nicht, da es sich nur um Daten handelt, nicht um eine Webseitenstruktur.

50
Robert Harvey

Das Hauptproblem besteht darin, dass der Server eng mit dem Client verbunden ist, der die HTML-Struktur kennen muss. Außerdem wird es schwieriger, die Endpunkte auf neue Weise oder in neuen Anwendungen wiederzuverwenden.

Wenn Sie einfache Daten zurückgeben und vom Client rendern lassen, wird die Kopplung verringert und die Flexibilität und Testbarkeit erhöht. Sie können Unit-Tests auf dem Client für Scheindaten und Unit-Tests auf dem Server ausführen, um die gewünschten Daten zu testen.

22
DeadMG

Ich denke du hast es ein bisschen rückwärts. Du sagst:

wir haben überhaupt keinen Test, daher haben wir keinen besonderen Grund, diesen JSON-Endpunkt zu erstellen

Ein Grund, einen geeigneten Endpunkt zu verwenden, wäre, dass Sie ihn könnten testen. Ich würde sagen, dass es ein sehr guter Grund ist, keine Tests zu haben, um einige zu schreiben. Das heißt, wenn es eine Logik gibt, die zum Testen geeignet wäre.

200.000 Codezeilen sind viel zu überarbeiten und wahrscheinlich schwer zu warten. Das Aufbrechen und Testen einiger Endpunkte ist möglicherweise ein guter Anfang.

Ein weiterer Grund könnte sein, den Server vom Client zu trennen. Wenn sich in ferner Zukunft das Anwendungsdesign oder -layout ändert, ist es einfacher, mit einem geeigneten Datenformat als mit HTML-Ausgabe zu arbeiten. In einer idealen Welt müssten Sie nur den Client ändern und den Server überhaupt nicht berühren.

14
Victor Sand

Es gibt drei Möglichkeiten (mindestens?), Eine Webseite aufzubauen:

  • Generieren Sie die gesamte Seite des Seitenservers.
  • Geben Sie eine Bare-Bones-Seite vom Server plus Code (JavaScript) zurück, und lassen Sie die Seite ihre Daten abrufen und auf der HTML-Clientseite rendern.
  • Geben Sie eine Teilseite plus Code zurück und lassen Sie den Code vorgerenderte HTML-Blöcke abrufen, die auf der Seite abgelegt werden können.

Der erste ist in Ordnung. Der zweite ist auch in Ordnung. Es ist der letzte, der das Problem ist.

Der Grund ist einfach: Sie haben jetzt geteilt die Konstruktion der HTML-Seite in vollständig getrennte Teile. Das Problem ist die Wartung. Jetzt haben Sie zwei separate Entitäten, die für die Verwaltung der Details der Benutzeroberfläche verantwortlich sind. Sie müssen also CSS und andere ähnliche Details zwischen den beiden separaten Teilen synchron halten. Sie haben die Breite der Seitenleiste geändert? Großartig. Das zurückkommende HTML-Fragment verursacht nun ein horizontales Scrollen, da die Annahmen über die Seitenleistenbreite nicht mehr gelten. Sie haben die Hintergrundfarbe für diesen Block geändert? Großartig, jetzt kollidiert die Schriftfarbe Ihres HTML-Fragments, da es eine andere Hintergrundfarbe angenommen hat und jemand vergessen hat, diesen Endpunkt zu testen.

Der Punkt ist, dass Sie jetzt Wissen aufgeteilt haben, das an einem einzigen Ort zentralisiert werden sollte (nämlich in der Präsentationslogik), und dies macht es schwieriger, sicherzustellen, dass alle Teile richtig zusammenpassen. Mithilfe einer JSON-API können Sie stattdessen die gesamte Logik nur im Front-End oder in Ihren serverseitigen Vorlagen beibehalten, wenn Sie Ihre Daten zunächst in HTML rendern. Es geht darum, das Präsentationswissen/die Präsentationslogik an einem einzigen Ort zu halten, damit es konsistent und als Teil eines einzigen Prozesses verwaltet werden kann. HTML/CSS/JS ist schwierig genug, um gerade zu bleiben, ohne es in viele kleine Teile zu zerlegen.

JSON-APIs haben außerdem den zusätzlichen Vorteil, dass die Daten völlig unabhängig von der Präsentationslogik verfügbar sind. Auf diese Weise können mehrere nterschiedliche Präsentatoren, z. B. eine mobile App und eine Webseite, dieselben Daten verwenden. Insbesondere können die Daten ohne Browser verwendet werden (z. B. mobile Apps oder nächtliche Cron-Jobs). Diese Konsumenten sind möglicherweise nicht einmal in der Lage, HTML zu analysieren. (Dies hängt natürlich zwangsläufig davon ab, dass die Daten zwischen den verschiedenen Verbrauchern gleich sind oder einer eine Teilmenge des anderen verwenden kann.) Ob Sie diese Funktion benötigen, hängt jedoch von den Anforderungen Ihrer speziellen Anwendung ab, während Sie Ihre Präsentation verwalten Logik ist trotzdem notwendig. Ich werde sagen, wenn Sie es im Voraus implementieren, sind Sie besser auf zukünftiges Wachstum vorbereitet.

6
jpmc26

Ich würde sagen, es ist nichts Falsches daran, dass der Server ein HTML-Fragment zurückgibt und die Benutzeroberfläche es .innerHTML eines Elements zuweist. Dies ist meiner Meinung nach der einfachste Weg, asynchronen JavaScript-Code zu entwickeln. Der Vorteil ist, dass so wenig wie möglich mit JavaScript und so viel wie möglich in einer kontrollierten Back-End-Umgebung ausgeführt wird. Denken Sie daran, dass die JavaScript-Unterstützung in Browsern unterschiedlich ist, Ihr Back-End jedoch immer dieselbe Version der Back-End-Komponenten hat. Dies bedeutet, dass so viel wie möglich im Back-End so wenig wie möglich Versionsinkompatibilitäten bedeutet.

Manchmal möchten Sie mehr als nur ein HTML-Fragment. Zum Beispiel ein Statuscode und ein HTML-Fragment. Anschließend können Sie ein JSON-Objekt mit zwei Elementen verwenden, statusCode und HTML, von denen das zweite nach Überprüfung des statusCode .innerHTML eines Elements zugewiesen werden kann. Die Verwendung von JSON und innerHTML sind also keineswegs alternative exklusive Ansätze. Sie können zusammen verwendet werden.

Mit JSON können Sie sogar mehrere HTML-Fragmente in derselben Antwort haben, die der .innerHTML mehrerer Elemente zugewiesen werden.

Zusammenfassend: Verwenden Sie .innerHTML. Dadurch ist Ihr Code mit möglichst vielen Browserversionen kompatibel. Wenn Sie mehr benötigen, verwenden Sie JSON und .innerHTML zusammen. Vermeiden Sie XML.

4
juhist

Es ist nichts falsch im Prinzip. Die Frage ist: Was möchten Sie erreichen?

JSON ist perfekt für die Datenübertragung. Wenn Sie stattdessen HTML senden und erwarten, dass der Client die Daten aus dem HTML extrahiert, ist das Müll.

Wenn Sie andererseits wollen HMTL übertragen, das als HTML gerendert werden soll, dann senden Sie es als HTML - anstatt den HTML-Code in eine Zeichenfolge zu packen, die Zeichenfolge in JSON umzuwandeln und JSON zu übertragen , es auf der anderen Seite dekodieren, eine Zeichenfolge abrufen und den HTML-Code aus der Zeichenfolge extrahieren.

Und erst gestern bin ich auf Code gestoßen, der zwei Elemente in ein Array eingefügt, das Array in JSON umgewandelt, das JSON in eine Zeichenfolge eingefügt, die Zeichenfolge in ein Array eingefügt, das gesamte Array in JSON umgewandelt und an den Client gesendet hat, der es dekodiert hat Der JSON erhielt ein Array mit einer Zeichenfolge, nahm die Zeichenfolge, extrahierte den JSON aus der Zeichenfolge, decodierte den JSON und erhielt ein Array mit zwei Elementen. Tu das nicht.

4
gnasher729

Dies alles hängt vom Zweck der API ab, aber im Allgemeinen ist das, was Sie beschreiben, eine ziemlich starke Verletzung von Trennung von Bedenken:

In einer modernen Anwendung sollte der API-Code für die Daten und der Client-Code für die Präsentation verantwortlich sein.

Wenn Ihre API HTML zurückgibt, koppeln Sie Ihre Daten und Ihre Präsentation eng miteinander. Wenn die API HTML zurückgibt, können Sie mit diesem HTML (einfach) nur es als Teil einer größeren Seite anzeigen. Aus einem anderen Blickwinkel ist das einzige, wofür die API gut ist, die Bereitstellung von HTML für Ihre Seite. Außerdem haben Sie Ihren HTML-Code sowohl auf den Client- als auch auf den Servercode verteilt. Dies kann die Wartung zu Kopfschmerzen machen.

Wenn Ihre API JSON oder eine andere Form von reinen Daten zurückgibt, wird dies viel nützlicher. Die vorhandene App kann diese Daten weiterhin verwenden und entsprechend darstellen. Jetzt können jedoch andere Dinge die API verwenden, um auf dieselben Daten zuzugreifen. Auch hier ist die Wartung einfacher - der gesamte HTML-Code befindet sich an einem Ort. Wenn Sie also die gesamte Site neu gestalten möchten, müssen Sie Ihre API nicht ändern.

3
SouthShoreAK

HTML ist an ein bestimmtes Design und eine bestimmte Verwendung gebunden.

Wenn Sie mit HTML das Seitenlayout ändern möchten, müssen Sie ändern, wie der HTML-Code vom Serveraufruf generiert wird. Normalerweise erfordert dies einen Back-End-Programmierer. Jetzt haben Sie Back-End-Programmierer, die per Definition nicht Ihre besten HTML-Autoren sind und diese Updates verwalten.

Wenn sich bei JSON das Seitenlayout ändert, muss sich der vorhandene JSON-Serveraufruf nicht unbedingt ändern. Stattdessen aktualisiert Ihr Front-End-Entwickler oder sogar der Designer die Vorlage, um aus denselben Basisdaten den gewünschten HTML-Code zu erstellen.

Darüber hinaus kann der JSON die Basis für andere Dienste werden. Möglicherweise haben Sie unterschiedliche Rollen, die dieselben Basisdaten auf unterschiedliche Weise anzeigen müssen. Beispielsweise haben Sie möglicherweise eine Kundenwebsite, auf der Daten zu einem Produkt auf einer Bestellseite angezeigt werden, und eine Innendienstseite für Mitarbeiter, auf der dieselben Daten in einem ganz anderen Layout angezeigt werden, möglicherweise zusammen mit einigen anderen Informationen, die allgemeinen Kunden nicht zur Verfügung stehen. Mit JSON kann in beiden Ansichten derselbe Serveraufruf verwendet werden.

Schließlich kann JSON besser skalieren. In den letzten Jahren sind wir mit clientseitigen Javascript-Frameworks über Bord gegangen. Ich denke, es ist Zeit, einen Schritt zurückzutreten und darüber nachzudenken, welches Javascript wir verwenden und wie es die Browserleistung beeinflusst ... insbesondere auf Mobilgeräten. Wenn Sie jedoch eine Site ausführen, die groß genug ist, um eine Serverfarm oder einen Cluster anstelle eines einzelnen Servers zu erfordern, kann JSON besser skaliert werden. Benutzer geben Ihnen in ihren Browsern kostenlos Verarbeitungszeit. Wenn Sie dies nutzen, können Sie die Serverlast in einer großen Bereitstellung reduzieren. JSON verbraucht auch weniger Bandbreite, also wieder wenn Sie groß genug sind und verwenden Sie es angemessen, JSON ist messbar billiger. Natürlich kann es auch schlechter skalieren, wenn Sie am Ende 40-KB-Bibliotheken einspeisen, um 2-KB-Daten in 7-KB-HTML-Dateien zu analysieren. Es lohnt sich also, sich dessen bewusst zu sein, was Sie tun. Aber das Potenzial ist für JSON da, um Leistung und Kosten zu verbessern.

2
Joel Coehoorn

An einem solchen Endpunkt ist nichts auszusetzen, wenn er seine Anforderungen erfüllt. Wenn es erforderlich ist, HTML auszuspucken, damit ein bekannter Verbraucher es effektiv analysieren kann, warum nicht?

Das Problem ist, dass Sie im allgemeinen Fall möchten, dass Ihre Endpunkte eine Nutzlast ausspucken, die von einem Standardparser wohlgeformt und effektiv analysiert werden kann. Und mit effektiv analysierbar meine ich deklarativ analysierbar.

Wenn Ihr Client gezwungen ist, die Nutzdaten zu lesen und offene Informationsbits mit Schleifen und if-Anweisungen daraus zu entfernen, ist er nicht effektiv analysierbar. Und HTML ist so, wie es ist, sehr vergeben, wenn es nicht verlangt, dass es gut geformt ist.

Wenn Sie nun sicherstellen, dass Ihr HTML-Code XML-kompatibel ist, sind Sie Gold wert.

Trotzdem habe ich ein erhebliches Problem damit:

Ich werde Ihnen Folgendes sagen: Ein Endpunkt, der HTML zurückgibt, verringert Ihre Abhängigkeit von JavaScript-Bibliotheken und verringert die Belastung des Benutzerbrowsers, da JS-Code zum Erstellen von DOM-Objekten nicht interpretiert/ausgeführt werden muss - der HTML-Code ist bereits vorhanden. Es geht nur darum, die Elemente zu analysieren und zu rendern. Dies bedeutet natürlich, dass es sich um eine angemessene Datenmenge handelt. 10 Megabyte HTML-Daten sind nicht sinnvoll.

Das ist eine schlechte Idee, egal wie Sie es schneiden. Jahrzehntelange kollektive Industrieerfahrung hat uns gezeigt, dass es im Allgemeinen eine gute Idee ist, Daten (oder Modelle) von ihrer Anzeige (oder Ansicht) zu trennen.

Hier verbinden Sie die beiden, um eine schnelle Ausführung des JS-Codes zu ermöglichen. Und das ist eine Mikrooptimierung.

Ich habe das nie als gute Idee gesehen, außer in sehr trivialen Systemen.

Mein Rat? Tu es nicht. HC SVNT DRACONES , YMMV usw.

1
luis.espinal

Es ist schwierig, ein Richtig oder ein Falsch zu kategorisieren. IMO, die Fragen, die ich stellen werde, sind: "sollte es" oder "kann es mit weniger tun?".

Jeder Endpunkt sollte sich bemühen, mit möglichst wenig Inhalten zu kommunizieren. Das Signal-Rausch-Verhältnis beträgt normalerweise HTTP-Codes <JSON <XHTML. In den meisten Situationen ist es gut, das am wenigsten verrauschte Protokoll zu wählen.

Ich unterscheide mich in Bezug auf das Laden von Client-Browsern durch @machado, da dies bei modernen Browsern kein Problem darstellt. Die meisten von ihnen sind ziemlich gut im Umgang mit HTTP-Codes und JSON-Antworten ausgestattet. Und obwohl Sie derzeit keine Tests haben, wäre die langfristige Wartung eines weniger verrauschten Protokolls billiger als das darüber liegende.

0
hazardous

JSON ist nur eine Textdarstellung strukturierter Daten. Ein Client benötigt natürlich einen Parser, um Daten zu verarbeiten, aber praktisch alle Sprachen verfügen über JSON-Parserfunktionen. Die Verwendung des JSON-Parsers ist wesentlich effizienter als die Verwendung des HTML-Parsers. Es braucht wenig Platz. Nicht so bei einem HTML-Parser.

In PHP verwenden Sie einfach json_encode($data) und es liegt an dem Client auf der anderen Seite, es zu analysieren. Wenn Sie JSON-Daten von einem Webdienst abrufen, verwenden Sie einfach $data=json_decode($response) und können entscheiden, wie Daten wie mit Variablen verwendet werden sollen.

Angenommen, Sie entwickeln eine App für ein mobiles Gerät. Warum benötigen Sie das HTML-Format, wenn mobile Apps den Webbrowser selten zum Parsen von Daten verwenden? Viele mobile Apps verwenden JSON (das am häufigsten verwendete Format), um Daten auszutauschen.

Warum möchten Sie HTML verwenden, das viel mehr Bandbreite benötigt als JSON, da Mobiltelefone häufig mit Messplänen ausgestattet sind?

Warum HMTL verwenden, wenn HTML in seinem Vokabular begrenzt ist und JSON Daten definieren kann? {"person_name":"Jeff Doe"} ist informativer als HTML über seine Daten liefern kann, da es nur die Struktur für HTML-Parser definiert, nicht Daten definiert.

JSON hat nichts mit HTTP zu tun. Sie können JSON in eine Datei einfügen. Sie können es für Konfigurationen verwenden. Composer verwendet JSON. Sie können damit auch einfache Variablen in Dateien speichern.

0
netrox