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

Unter Grenzenlos haben wir uns mit Option 2 intensiv beschäftigt und sie für Tausende von Schülern eingeführt. Unser Server ist eine JSON REST API (Scala + MongoDB), und unser gesamter Client-Code wird direkt von CloudFront bereitgestellt (d.h. www.boundless.com ist nur ein Alias für CloudFront).

Vorteile:

• Innovativ/aufregend
• Viel Leistung für Ihr Geld: Die API bietet Ihnen die Grundlage für Ihren eigenen Web-Client, mobile Clients, den Zugang von Drittanbietern usw.
• äußerst schnelles Laden der Website / Seitenübergänge

Nachteile:

• Nicht SEO-freundlich/bereit ohne viel mehr Arbeit.
• Erfordert erstklassige Web-Frontend-Leute, die bereit sind, mit der Realität einer Website zurechtzukommen, die zu 70% aus Javascript besteht, und was das bedeutet.

Ich glaube, dass dies die Zukunft aller Webanwendungen ist.

Einige Gedanken für die Web-Front-End-Leute (wo die ganze Neuheit/Herausforderung bei dieser Architektur liegt):

• CoffeeScript. Es ist viel einfacher, hochwertigen Code zu produzieren.
• Backbone. Großartige Möglichkeit, Ihre Logik zu organisieren, und aktive Gemeinschaft.
• HAMLC. Haml + CoffeeScript-Vorlagen => JS.
• SASS

Wir haben für unsere Front-End-Entwicklung ein Harness namens 'Spar' (Single Page App Rocketship) entwickelt, bei dem es sich um die Asset-Pipeline von Rails handelt, die auf die Entwicklung von Single-Page-Apps abgestimmt ist. Wir werden es in den nächsten Wochen auf unserer Website für alle zugänglich machen. github Seite sowie einen Blogbeitrag, in dem die Verwendung und die allgemeine Architektur näher erläutert werden.

UPDATE:

Was die Bedenken der Leute gegenüber Backbone angeht, so halte ich sie für überbewertet. Backbone ist viel mehr ein Organisationsprinzip als ein tiefes Framework. Twitters Website selbst ist ein riesiges Biest von Javascript, das jede Ecke über Millionen von Nutzern und Legacy-Browsern abdeckt, während es Tweets in Echtzeit lädt, Müll sammelt, viele Multimedia-Inhalte anzeigt, usw. Von allen "reinen" Javascript-Websites, die ich gesehen habe, ist Twitter der Sonderling. Es gibt viele beeindruckend komplizierte Anwendungen, die über JS bereitgestellt werden und sehr gut funktionieren.

Und die Wahl der Architektur hängt ganz von Ihren Zielen ab. Wenn Sie den schnellsten Weg suchen, um mehrere Kunden zu unterstützen und Zugang zu guten Front-End-Talenten haben, ist die Investition in eine eigenständige API eine gute Wahl.

Answer 2

Sehr gut gefragt. +1. Sicherlich ist dies künftig nützliche Referenz für mich. Auch @Aaron und andere haben einen Beitrag zur Diskussion geleistet. Wie Ruby, ist diese Frage auch auf andere Programmierumgebungen anwendbar.

Ich habe die ersten beiden Möglichkeiten genutzt. Die erste für zahlreiche Anwendungen und die zweite für mein Open-Source-Projekt Cowoop

Option 1

Diese ist zweifellos die beliebteste. Aber ich finde, die Implementierung ist sehr http-artig. Der anfängliche Code einer jeden API befasst sich mit dem Request-Objekt. So API-Code ist mehr als reine Ruby/Python/andere Sprache Code.

Option 2

Ich habe das immer geliebt.

Diese Option bedeutet auch, dass HTML nicht zur Laufzeit auf dem Server generiert wird. Darin unterscheidet sich Option 2 von Option 3. Sie werden jedoch als statisches HTML mithilfe eines Build-Skripts erstellt. Beim Laden auf der Client-Seite würden diese HTML-Dateien den API-Server als JS-API-Client aufrufen.

• Die Trennung der Interessen ist ein großer Vorteil. Und ganz nach Ihrem Geschmack (und meinem) implementieren Backend-Experten Backend-APIs, testen sie einfach wie gewöhnlichen Sprachcode, ohne sich um Framework/Http-Anfragecode zu kümmern.

• Das ist wirklich nicht so schwierig, wie es auf der Frontend-Seite klingt. Führen Sie API-Aufrufe und resultierende Daten (meist json) ist für Ihre Client-Seite Vorlage oder MVC zur Verfügung.

• Weniger serverseitige Verarbeitung. Das bedeutet, dass Sie sich für Standard-Hardware/weniger teure Server entscheiden können.

• Es ist einfacher, Schichten unabhängig zu testen und API-Dokumente zu erstellen.

Sie hat allerdings auch einige Schattenseiten.

• Viele Entwickler empfinden dies als übertechnisiert und schwer verständlich. Daher besteht die Gefahr, dass die Architektur kritisiert wird.

• i18n/l10n ist schwierig. Da HTML im Wesentlichen generiert wird, sind Build-Zeiten statisch, man braucht mehrere Builds pro unterstützter Sprache (was nicht unbedingt eine schlechte Sache ist). Aber auch damit können Sie Eckfälle um l10n/i18n haben und müssen vorsichtig sein.

Option 3

Die Backend-Codierung muss in diesem Fall dieselbe sein wie bei der zweiten Option. Die meisten Punkte für Option 2 sind auch hier anwendbar.

Webseiten werden zur Laufzeit mit serverseitigen Vorlagen gerendert. Dies macht i18n/l10n mit etablierteren/akzeptierten Techniken viel einfacher. Möglicherweise ist ein http-Aufruf für einige wesentliche Kontexte, die für das Rendering der Seite benötigt werden, wie Benutzer, Sprache, Währung usw., weniger erforderlich. Die serverseitige Verarbeitung wird also durch das Rendering erhöht, aber möglicherweise durch weniger http-Aufrufe an den API-Server kompensiert.

Da die Seiten nun auf dem Server gerendert werden, ist das Frontend nun stärker mit der Programmierumgebung verbunden. Für viele Anwendungen ist dies vielleicht nicht einmal eine Überlegung wert.

Twitter-Fall

Wie ich verstehe, könnte Twitter ihre anfängliche Seite Rendering auf dem Server, sondern für Seiten-Updates hat es noch einige API-Aufrufe und Client-seitige Vorlagen zu manipulieren DOM. In einem solchen Fall müssen Sie also zwei Templates pflegen, was einen gewissen Overhead und Komplexität mit sich bringt. Nicht jeder kann sich diese Option leisten, im Gegensatz zu Twitter.

Unser Projekt Stack

Ich verwende zufällig Python. Ich verwende JsonRPC 2.0 anstelle von REST. Ich schlage REST vor, obwohl ich die Idee von JsonRPC aus verschiedenen Gründen mag. Ich verwende folgende Bibliotheken. Jemand, der Option 2/3 in Betracht zieht, könnte sie nützlich finden.

• API-Server: Python Ein schnelles Web-Mikro-Framework - Flachmann
• Frontend-Server: Nginx
• Kundenseitiges MVC: Knockout.js
• Andere relevante Tools/Libs:
  • Jquery
  • Buchhaltung.js für Geldwährung
  • Webshim : Browserübergreifendes Polyfill
  • Direktor : Client-seitiges Routing
  • sphc : HTML-Erstellung

Meine Schlussfolgerung und Empfehlung

Option 3.

Abgesehen davon habe ich Option 2 erfolgreich genutzt, neige aber jetzt der Einfachheit halber zu Option 3. Statische HTML-Seiten mit Build-Skript zu generieren und sie mit einem ultraschnellen Server, der auf die Bereitstellung statischer Seiten spezialisiert ist, zu bedienen, ist sehr verlockend (Option 2).

Answer 3

Beim Aufbau von gaug.es haben wir uns für die Nummer 2 entschieden. Ich arbeitete an der API (Ruby, Sinatra, etc.) und mein Geschäftspartner Steve Smith arbeitete am Frontend (Javascript-Client).

Vorteile:

1. Bewegen Sie sich schnell und parallel. Wenn ich vor Steve arbeiten würde, könnte ich weiterhin APIs für neue Funktionen erstellen. Wenn er vor mir arbeitete, konnte er die API ganz einfach fälschen und die Benutzeroberfläche erstellen.

2. API kostenlos. Der offene Zugang zu den Daten in Ihrer Anwendung wird schnell zu einem Standardmerkmal. Wenn Sie von Grund auf mit einer API beginnen, erhalten Sie diese kostenlos.

3. Saubere Trennung. Es ist besser, Ihre Anwendung als eine API mit Clients zu betrachten. Sicher, der erste und wichtigste Client ist vielleicht ein Web-Client, aber damit können Sie leicht andere Clients erstellen (iPhone, Android).

Nachteile:

1. Rückwärtskompatibilität. Das hat mehr mit einer API zu tun als mit Ihrer direkten Frage, aber wenn Ihre API erst einmal da ist, können Sie sie nicht einfach kaputt machen, oder Sie machen alle Ihre Kunden kaputt. Das bedeutet nicht, dass Sie langsamer vorgehen müssen, aber es bedeutet, dass Sie oft zwei Dinge auf einmal zum Laufen bringen müssen. Das Hinzufügen zur API oder neuer Felder ist in Ordnung, aber das Ändern/Entfernen sollte nicht ohne Versionierung erfolgen.

Mehr Nachteile fallen mir im Moment nicht ein.

Schlussfolgerung: API + JS-Client ist der richtige Weg, wenn Sie planen, eine API zu veröffentlichen.

P.S. Ich würde auch empfehlen, Ihre API vollständig zu dokumentieren, bevor Sie sie veröffentlichen. Der Prozess der Dokumentation der Gaug.es-API hat uns wirklich geholfen, die

http://get.gaug.es/documentation/api/

Answer 4

Ich ziehe es vor, den Weg von #2 und #3 zu gehen. Vor allem, weil Nr. 1 gegen die Trennung von Belangen verstößt und alle möglichen Dinge miteinander vermischt. Irgendwann werden Sie feststellen, dass Sie einen API-Endpunkt brauchen, der keine passende HTML-Seite/etc. hat, und dann haben Sie ein Problem mit vermischten HTML- und JSON-Endpunkten in derselben Codebasis. Es verwandelt sich in ein verdammtes Chaos, auch wenn seine MVP, müssen Sie es schließlich neu zu schreiben, weil seine soo chaotisch, dass seine nicht einmal wert zu retten.

Wenn Sie sich für Nr. 2 oder Nr. 3 entscheiden, können Sie eine API verwenden, die sich (größtenteils) immer gleich verhält. Dies bietet große Flexibilität. Ich bin nicht 100% auf Backbone / Mitglied / was auch immer / etc.js gerade noch verkauft. Ich denke, es ist großartig, aber wie wir mit Twitter sehen, ist dies nicht optimal. ABER... Twitter ist auch ein riesiges Unternehmen mit Hunderten von Millionen von Nutzern. Jede Verbesserung kann also enorme Auswirkungen auf das Endergebnis in verschiedenen Bereichen verschiedener Geschäftseinheiten haben. Ich glaube, hinter der Entscheidung steckt mehr als nur Geschwindigkeit, und das verraten sie uns nicht. Aber das ist nur meine Meinung. Ich schließe Backbone und seine Konkurrenten jedoch nicht aus. Diese Anwendungen sind großartig zu benutzen, sehr sauber und reagieren (größtenteils) sehr schnell.

Auch die dritte Option hat einen gewissen Reiz. Hier würde ich dem Pareto-Prinzip (80/20-Regel) folgen und 20 % Ihres Hauptmarkups (oder umgekehrt) auf dem Server rendern lassen und dann einen schönen JS-Client (Backbone/etc) für den Rest einsetzen. Sie können nicht zu 100% mit der REST-Api über den JS-Client kommunizieren, aber Sie werden einige Arbeit tun, wenn nötig, um die suer Erfahrung besser zu machen.

Ich denke, das ist eines dieser Probleme, bei denen es darauf ankommt, und die Antwort lautet: Es kommt darauf an, was Sie tun, wem Sie dienen und welche Art von Erfahrung Sie ihnen vermitteln wollen. In Anbetracht dessen denke ich, dass man sich für 2 oder 3 oder eine Mischung aus beiden entscheiden kann.

Answer 5

Ich bin in der Regel für die 2. Option, mit Rails, um die API zu bauen, und Backbone für die JS Zeug. Sie können sogar ein Admin-Panel kostenlos erhalten mit ActiveAdmin . Ich habe Dutzende von mobilen Anwendungen mit dieser Art von Backend ausgeliefert. Allerdings hängt es stark davon ab, ob Ihre App interaktiv ist oder nicht.

Auf der letzten Konferenz habe ich einen Vortrag über diesen Ansatz gehalten. RubyDay.it : http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

Für die dritte Option, um die Reaktionsfähigkeit der zweiten Option zu erreichen, können Sie versuchen pajax wie bei Github.