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 habe für einen hybriden Ansatz gegangen, wo wir Benutzer Sinatra als Basis, ActiveRecord / Postgress usw. zu dienen, Seite Routen (schlanke Vorlagen) eine REST-API die Web-App verwenden können aussetzen. In der frühen Entwicklung Sachen wie Populating Select-Optionen wird über Helfer Rendering in die schlanke Vorlage getan, aber wie wir die Produktion nähern wird dies für einen AJAX-Aufruf an eine REST-API ausgetauscht, wie wir beginnen, mehr über Seite-Ladegeschwindigkeiten und so weiter zu kümmern.

Dinge, die leicht in Slim gerendert werden können, werden auf diese Weise gehandhabt, und Dinge (das Ausfüllen von Formularen, der Empfang von POST-Daten von jQuery.Validation's submitHandler usw., ist alles offensichtlich AJAX)

Tests sind ein Thema. Im Moment bin ich ratlos Versuch, JSON-Daten an einen Rack::Test POST-Test zu übergeben .

Answer 2

Ich persönlich bevorzuge Option (3) als Lösung. Sie wird in so gut wie allen Websites eines früheren (bekannten) Arbeitgebers von mir verwendet. Es bedeutet, dass Sie einige Front-End-Entwickler, die alles über Javascript, Browser Macken und was weiß ich nicht alles wissen, um Ihr Frontend zu programmieren. Sie müssen nur wissen, "curl xyz und Sie erhalten einige json" und los geht's.

In der Zwischenzeit können Ihre schwergewichtigen Backend-Mitarbeiter die Json-Anbieter programmieren. Diese Leute müssen sich überhaupt keine Gedanken über die Präsentation machen und kümmern sich stattdessen um unzuverlässige Backends, Timeouts, elegante Fehlerbehandlung, Datenbankverbindungspools, Threading und Skalierung usw.

Mit Option 3 erhalten Sie eine gute, solide dreistufige Architektur. Es bedeutet, dass das Zeug, das Sie aus dem Frontend spucken, SEO-freundlich ist, kann gemacht werden, um mit alten oder neuen Browsern (und solche mit JS ausgeschaltet) zu arbeiten, und könnte immer noch Javascript Client-seitige Templating sein, wenn Sie wollen (so könnten Sie Dinge tun, wie alte Browser / Googlebot mit statischem HTML zu behandeln, aber senden JS gebaut dynamische Erfahrungen für Menschen mit dem neuesten Chrome-Browser oder was auch immer).

In allen Fällen, in denen ich Option 3 gesehen habe, handelte es sich um eine benutzerdefinierte PHP-Implementierung, die nicht besonders gut zwischen Projekten übertragbar ist, geschweige denn in das Open-Source-Land. Ich vermute, dass PHP in letzter Zeit durch Ruby/Rails ersetzt wurde, aber das Gleiche gilt immer noch.

FWIW, $current_employer könnte an einigen wichtigen Stellen mit Option 3 arbeiten. Ich bin auf der Suche nach einem guten Ruby-Framework, in dem ich etwas aufbauen kann. Ich bin sicher, ich kann eine Ladung von Edelsteinen zusammenkleben, aber ich würde ein einzelnes Produkt bevorzugen, die im Großen und Ganzen ein Templating, "Curling", optional-Authentifizierung, optional Memcache/nosql verbunden Caching-Lösung bietet. Hier scheitere ich daran, etwas Kohärentes zu finden :-(

Answer 3

Der Aufbau einer JSON-API in Rails ist erstklassig. Das JSONAPI::Resources-Gem erledigt die schwere Arbeit für eine http://jsonapi.org spezifizierte API.