Ist das "Anti-Muster" und sollte ich es nicht mehr verwenden oder ist das ein cleveres Design?

Grundsätzlich habe ich beim Erstellen eines REST-Service Folgendes angestrebt:

1. HTML wird angefordert
2. Der Dienst gibt die gewünschte Webseite zurück, jedoch ohne die angeforderte "Ressource", z. Daten
3. Die Webseite enthält JavaScript, das eine AJAX-Anforderung an denselben Dienst sendet (unterschiedlicher Inhaltstyp).
4. Der Dienst gibt dann die tatsächlichen Daten (JSON) zurück und die Seite zeigt sie an

Auf der einen Seite scheint es ineffizient zu sein (2 Anfragen), aber wenn ich dies verwendet habe, ist "Leistung kein Problem", was bedeutet, dass die interne App mit geringem Datenverkehr und die Websites einfach sind und schnell geladen werden.

Der Grund, warum ich dazu gekommen bin, ist, dass die Webseite dann fast reines HTML + JavaScript sein kann und fast kein serverseitiges Material erforderlich ist, insbesondere keine Schleifen, um Tabellen und ähnliches zu erstellen (was ich im Vergleich dazu sehr hässlich finde Dinge wie slickgrid), zB Trennung von Daten und Ansicht.

Ist dies eine gute Idee, bevor ich damit anfange, oder sollte ich einfach damit aufhören?

Wenn Sie eine Ressource anfordern und diese keine Daten enthält, handelt es sich nicht um einen REST-Service. Der Dienst, der die tatsächlichen Daten in json bereitstellt, ist dies möglicherweise, der HTML-Teil jedoch nicht. Für eine Webanwendung spielt es keine Rolle.

Die Technik funktioniert, aber Sie müssen sich der Einschränkungen bewusst sein:

1. Suchmaschinen interpretieren kein JavaScript, daher ist eine so implementierte Website für Google und ähnliche Unternehmen nicht indizierbar. Für die interne Anwendung spielt es keine Rolle, für die Öffentlichkeit ist es sehr wichtig.
2. Benutzer mit besonderen Bedürfnissen (wie diejenigen, die Braille-Terminals verwenden) verwenden spezielle Browser, die eher eingeschränkt sind und das JavaScript möglicherweise nicht richtig interpretieren.

Ich würde auch bemerken, dass der Code, der den HTML-Code generiert, grundsätzlich der gleiche ist, unabhängig davon, ob er serverseitig oder clientseitig ausgeführt wird. Sie haben eine viel größere Auswahl an Sprachen und Frameworks auf der Serverseite, und ich bin sicher, dass es auch mehrere Äquivalente von Slickgrid gibt.

Sie können und sollten weiterhin die Trennung von Daten und Anzeige auf der Serverseite beibehalten. Das Vorlagensystem kann und sollte die Daten einfach als Datenstruktur oder sogar als json verwenden (insbesondere wenn der eigentliche Dienst in einer anderen Sprache als das Vorlagensystem vorliegt) und einfach eine Vorlage mit diesen Daten erweitern.

Und nein, ich denke nicht an PHP; Es ist das am wenigsten leistungsfähige Vorlagensystem da draußen (obwohl es einige bessere gibt, die darauf aufbauen). Ich denke an Genshi oder XSLT oder etwas noch Fortgeschritteneres, das Web-Widgets bereitstellt.

Daran ist nichts auszusetzen, solange Sie sicherstellen, dass Ihr Code sauber strukturiert ist. Sie können den statischen Inhalt sogar von einem Apache anstelle Ihres Webdienstes bereitstellen.

Dies ist eine gute Praxis. Und es wird die ganze Zeit gemacht, obwohl @JanHudec darauf hinweist, dass es falsch ist, es als REST-Service zu bezeichnen. Aber viele Websites tun genau dies aus genau den Gründen, auf die Sie hinweisen.

Ich würde es nicht als Anti-Pattern bezeichnen. Was Sie beschreiben, ist mehr oder weniger ein fetter Kunde , nicht ganz anders als bei Diensten wie Trello. Die anfängliche Verantwortung des Servers besteht darin, das DOM und alle Ressourcen zu senden, die erforderlich sind, damit der Client funktioniert. Ich habe an ähnlichen Projekten in der Automatisierung von Rechenzentren und der Netzwerküberwachung gearbeitet.

Der Client startet als spärliches DOM, zieht einige Daten über XHR (manchmal über JSONP) ab und verbindet sich schließlich mit einem Socket-Server. Ein noch grundlegenderes Beispiel wäre eine Chat-Anwendung.

Der einzige Grund, es nicht zu tun, ist, dass es extrem schwierig sein kann, es richtig zu machen. Wenn Sie mit der asynchronen Funktionsprogrammierung und allen damit verbundenen Rennen und anderen Herausforderungen vertraut sind, können Sie sie problemlos warten. Noch wichtiger ist, dass Sie kein Problem damit haben, es zu schreiben, damit andere Leute es schließlich pflegen können.

Wenn Ihnen der Gedanke, weitere Funktionen hinzuzufügen, Angst macht oder Sie feststellen, dass das Debuggen ein Albtraum ist, sollten Sie andere Methoden in der Produktion in Betracht ziehen, während Sie weiter experimentieren und lernen.

Es ist ein gültiges Design, solange Sie kein Loch für sich selbst graben. Wenn Sie überall Gobs und Gobs von zufälligen JS anstelle einer sauberen Schnittstelle haben, möchten Sie das Projekt wahrscheinlich neu faktorisieren oder anders ausführen. Die meisten Ihrer Funktionen, deren Ausführung nach dem Laden aller Ressourcen definiert ist, sollten anonym sein und über eine saubere Schnittstelle eingegeben werden. Wenn dies nicht der Fall ist, könnten Sie in Schwierigkeiten geraten.

Wie @Jan Hudec sagte, kann Ihr Ansatz definitiv nicht als REST bezeichnet werden. Obwohl der Teil, in dem der Client eine Ressource anfordert, sein könnte. Es ist besser, wenn der Client den Präsentationsteil wie backbonefolgt behandelt. Es kommuniziert mit dem REST-Server für die Ressourcen und zeigt sie mit an views.

Es mag ein Anti-Pattern sein, aber ich denke, es ist auch die Zukunft von Webanwendungen. Anstatt mit JavaScript herumzuspielen, sollten Sie jedoch mindestens eine Vorlagenbibliothek verwenden. Eine bessere Lösung ist ein clientseitiges MVC-Framework wie AngularJS (das ich gerade verwende).

Weitere Referenzen finden Sie in einem beliebten Blog-Beitrag , in dem mehrere Frameworks verglichen werden. Auf dieser Website wird dasselbe Programm mithilfe mehrerer Frameworks implementiert.

Außerdem: Jan Hudecs Kommentare zur Interaktion zwischen Suchmaschinen und Bildschirmlesern sind gültig. Wenn Sie an einer E-Commerce-Site arbeiten (wo Pagerank wichtig ist), möchten Sie wahrscheinlich keine clientseitigen Frameworks verwenden. Bei internen Apps sind dies jedoch normalerweise keine Probleme.

Was du tust, hört sich gut an! Wenn Ihre JSON-Antworten jedoch HTML enthalten, verschwenden Sie Ihre Zeit.

Ein weiterer Punkt ist jedoch, dass Ihr dummer Client wahrscheinlich seine JSON-Daten aus einem anderen Projekt beziehen sollte. Sie sollten eine ordnungsgemäße Trennung zwischen Kunde und Service anstreben, um einen ordnungsgemäßen RESTful-Service zu erhalten