Getrennter REST JSON API Server und Client?

Question

Ich bin gerade dabei, eine Reihe von Webanwendungen von Grund auf neu zu erstellen. (Siehe http://50pop.com/code zur Übersicht). Ich möchte, dass sie von vielen verschiedenen Clients aus aufgerufen werden können: Front-End-Websites, Smartphone-Apps, Back-End-Webservices usw. Ich möchte also wirklich eine JSON REST API für jeden einzelnen.

Außerdem bevorzuge ich es, am Back-End zu arbeiten. Daher träume ich davon, dass ich mich ausschließlich auf die API konzentriere und jemand anderen mit der Erstellung der Benutzeroberfläche beauftrage, sei es eine Website, ein iPhone, eine Android- oder eine andere Anwendung.

Bitte helfen Sie mir bei der Entscheidung, welchen Weg ich einschlagen soll:

ZUSAMMEN IN SCHIENEN

Erstellen Sie eine ganz normale Rails-Webanwendung. In der Steuerung, tun Sie die respond_with Schalter, um entweder JSON oder HTML zu dienen. Die JSON-Antwort ist dann meine API.

Pro: Es gibt viele Präzedenzfälle. Tolle Standards und viele Beispiele dafür, wie man es machen kann.

Betrug: Die API muss nicht unbedingt mit der Webanwendung identisch sein. Ich mag den if/then respond_with switch Ansatz nicht. Vermischen von zwei sehr unterschiedlichen Dingen (UI + API).

REST-SERVER + JAVASCRIPT-LASTIGER CLIENT

Erstellen Sie einen reinen JSON-REST-API-Server. Verwenden Sie Backbone oder Ember.js für clientseitiges JavaScript, um direkt auf die API zuzugreifen und die Vorlagen im Browser anzuzeigen.

Pro: Ich liebe die Trennung von API und Client. Kluge Leute sagen, dass dies der richtige Weg ist. In der Theorie großartig. Scheint hochmodern und aufregend zu sein.

Betrug: Es gibt nicht viele Präzedenzfälle. Es gibt nicht viele gute Beispiele dafür. Öffentliche Beispiele (twitter.com) fühlen sich träge an und sind sogar dabei, von diesem Ansatz abzuweichen.

REST SERVER + SERVER-SEITIGER HTML-CLIENT

Erstellen Sie einen reinen JSON-REST-API-Server. Erstellen Sie einen einfachen HTML-Website-Client, der nur auf die REST-API zugreift. Weniger clientseitiges JavaScript.

Pro: Ich liebe die Trennung von API und Client. Aber die Bereitstellung von einfachem HTML5 ist ziemlich narrensicher und nicht Client-intensiv.

Betrug: Es gibt nicht viele Präzedenzfälle. Nicht viele Beispiele für eine gute Umsetzung. Die Rahmenwerke unterstützen dies nicht so gut. Nicht sicher, wie man es angehen soll.

Ich suche vor allem nach Ratschlägen aus der Praxis, nicht nur aus der Theorie.

Answer 1

Ich bin gerade dabei, ein großes CMS von Option 1 auf Option 3 umzustellen, und es läuft gut. Wir haben uns dafür entschieden, das Markup serverseitig zu rendern, weil SEO für uns eine große Sache ist und wir wollen, dass die Seiten auf Mobiltelefonen gut funktionieren.

Ich verwende node.js für das Back-End des Kunden und eine Handvoll Module, um mir zu helfen. Ich bin etwas früh in den Prozess, aber die Grundlage ist gesetzt und es ist eine Frage der gehen über die Daten sicherzustellen, dass es alle richtig rendert. Hier ist, was ich verwende:

• Express für die Grundlage der App.
  (https://github.com/visionmedia/express)
• Anfrage zum Abrufen der Daten.
  (https://github.com/mikeal/request)
• Underscore-Vorlagen, die serverseitig gerendert werden. Ich verwende diese auf dem Client wieder.
  (https://github.com/documentcloud/underscore)
• UTML wickelt die Vorlagen von underscore ein, damit sie mit Express funktionieren.
  (https://github.com/mikefrey/utml)
• Upfront sammelt Vorlagen und lässt Sie auswählen, welche an den Kunden geschickt werden.
  (https://github.com/mrDarcyMurphy/upfront)
• Express Expose übergibt die abgerufenen Daten, einige Module und Vorlagen an das Front-End.
  (https://github.com/visionmedia/express-expose)
• Backbone erstellt Modelle und Ansichten auf dem Frontend, nachdem es die weitergegebenen Daten geschluckt hat.
  (https://github.com/documentcloud/backbone)

Das ist der Kern des Stapels. Einige andere Module, die ich als hilfreich empfunden habe:

• fleck (https//github.com/trek/fleck)
• Moment (https//github.com/timrwood/moment)
• Griffel (https//github.com/LearnBoost/stylus)
• smoosh (https//github.com/fat/smoosh)
  obwohl ich mir Grunt anschaue (https//github.com/cowboy/grunt)
• Konsolenspur (//github.com/LearnBoost/console-trace).

Nein, ich verwende kein Coffeescript.

Diese Option funktioniert bei mir sehr gut. Die Modelle auf dem Back-End sind nicht existent, weil die Daten, die wir von der API erhalten, gut strukturiert sind und ich sie wortwörtlich an das Front-End weitergebe. Die einzige Ausnahme ist unser Layout-Modell, dem ich ein einziges Attribut hinzufüge, das das Rendering intelligenter und leichter macht. Dafür habe ich keine ausgefallene Modellbibliothek verwendet, sondern nur eine Funktion, die bei der Initialisierung hinzufügt, was ich brauche, und sich selbst zurückgibt.

(Entschuldigung für die seltsamen Links, ich bin zu sehr ein N00b für Stack Overflow, um so viele zu posten)

Answer 2

Wir verwenden die folgende Variante von #3: Erstellen Sie einen reinen JSON-REST-API-Server. Erstellen Sie einen HTML-Website-Server. Der HTML-Webserver ist nicht, wie in Ihrer Variante, ein Client für den REST-API-Server. Stattdessen sind die beiden Peers. Nicht weit unter der Oberfläche gibt es eine interne API, die die Funktionen bereitstellt, die die beiden Server benötigen.

Uns ist kein Präzedenzfall bekannt, also ist es eine Art Experiment. Bislang (wir stehen kurz vor dem Eintritt in die Beta-Phase) hat es ziemlich gut funktioniert.

Answer 3

Ich befinde mich seit etwa 2 Monaten in einem 3-monatigen Projekt, das den zweiten Ansatz verfolgt, den Sie hier skizziert haben. Wir verwenden eine RESTful API Server-Seite mit Backbone.js auf der Vorderseite. Handlebars.js verwaltet die Vorlagen und jQuery übernimmt die AJAX- und DOM-Manipulation. Für ältere Browser und Suchspider sind wir auf das serverseitige Rendering zurückgefallen, aber wir verwenden die gleichen HTML-Vorlagen wie das Handlebars-Frontend mit Mozilla Rhino.

Wir haben uns aus verschiedenen Gründen für diesen Ansatz entschieden, sind uns aber auch bewusst, dass er ein gewisses Risiko birgt, da er sich noch nicht auf breiter Ebene bewährt hat. Trotzdem läuft bisher alles ziemlich reibungslos.

Bislang haben wir nur mit einer API gearbeitet, aber in der nächsten Phase des Projekts werden wir mit einer zweiten API arbeiten. Die erste ist für große Datenmengen gedacht, und die zweite funktioniert eher wie ein CMS über eine API.

Die Tatsache, dass diese beiden Teile des Projekts völlig unabhängig voneinander agieren, war ein wichtiger Aspekt bei der Auswahl dieser Infrastruktur. Wenn Sie auf der Suche nach einer Architektur sind, mit der Sie verschiedene unabhängige Ressourcen ohne jegliche Abhängigkeiten zusammenführen können, dann ist dieser Ansatz einen Blick wert.

Ich fürchte, ich bin kein Ruby-Kenner, daher kann ich mich nicht zu den anderen Ansätzen äußern. Manchmal ist es in Ordnung, ein Risiko einzugehen. Andere Male ist es besser, auf Nummer sicher zu gehen. Das hängt von der Art des Projekts ab.

Ich wünsche Ihnen viel Glück bei Ihrer Wahl. Ich bin gespannt, was die anderen auch berichten.

Answer 4

Ich mag #3, wenn meine Website nicht eine 100%ige CRUD-Implementierung meiner Daten sein wird. Was noch nicht der Fall ist.

Ich bevorzuge Sinatra und werde die App einfach in ein paar verschiedene Rack-Apps mit unterschiedlichen Zwecken aufteilen. Ich werde eine API-spezifische Rack-App machen, die abdeckt, was ich für die API brauche. Dann vielleicht eine Benutzer-Rack-App, die meine Webseite präsentiert. Manchmal wird diese Version die API bei Bedarf abfragen, aber normalerweise kümmert sie sich nur um die HTML-Seite.

Ich kümmere mich nicht darum und mache einfach eine Abfrage der Persistenzschicht von der Benutzerseite aus, wenn ich sie brauche. Ich bin nicht übermäßig besorgt mit der Schaffung einer vollständigen Trennung, da sie in der Regel am Ende für verschiedene Zwecke dienen.

Hier ist ein muy einfaches Beispiel für die Verwendung mehrerer Rack-Anwendungen. Ich habe ein kurzes Jquery-Beispiel eingefügt, damit Sie sehen können, wie es auf die API-App trifft. Sie können sehen, wie einfach es mit Sinatra und Montage mehrere Rack-Anwendungen mit unterschiedlichen Zwecken sein kann.

https://github.com/dusty/multi-rack-app-app

Answer 5

Ich würde auf jeden Fall #2 oder #3 empfehlen - die Trennung ist nicht nur konzeptionell, sondern auch in der Praxis gut.

Es kann schwierig sein, Dinge wie Last- und Verkehrsmuster bei einer API vorherzusagen, und Kunden, die die API unabhängig bedienen, haben es bei der Bereitstellung und Skalierung leichter. Wenn man das mit menschlichen Webzugriffsmustern in Einklang bringen muss, ist das weniger einfach. Außerdem kann es sein, dass Ihre API-Nutzung viel schneller ansteigt als Ihr Web-Client, und dann können Sie sehen, wohin Sie Ihre Bemühungen lenken sollten.

Zwischen #2 #3 hängt es wirklich von Ihren Zielen ab - ich würde zustimmen, dass #2 wahrscheinlich die Zukunft von Webapps ist - aber vielleicht wollen Sie etwas einfacheres, wenn dieser Kanal nur einer von vielen sein wird!