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

Für atyourservice.com.cy verwenden wir serverseitig gerenderte Vorlagen für die Seiten, insbesondere um den Se-Teil abzudecken. Und wir verwenden die API für Interaktionen nach dem Laden der Seite. Da unser Framework MVC ist, werden alle Controller-Funktionen in die json-Ausgabe und html-Ausgabe dupliziert. Templates sind sauber und erhalten nur ein Objekt. Dieses kann in Sekundenschnelle in js-Templates umgewandelt werden. Wir behalten die serverseitigen Vorlagen immer bei und wandeln sie nur auf Anfrage in js um.

Answer 2

Isomorphes Rendering und progressive Verbesserung. Ich glaube, das ist es, worauf Sie mit Option drei hinauswollten.

isomorphes Rendering bedeutet, dass Sie für die serverseitige Generierung von Markup dieselbe Vorlage verwenden, die Sie auch für den clientseitigen Code verwenden. Wählen Sie eine Templating-Sprache mit guten server- und clientseitigen Implementierungen. Erstellen Sie für Ihre Benutzer vollständig ausgearbeitetes HTML und senden Sie es über die Leitung. Verwenden Sie auch Caching.

schrittweise Anhebung bedeutet, dass Sie mit der clientseitigen Ausführung, dem Rendering und dem Abhören von Ereignissen beginnen, sobald Sie alle Ressourcen heruntergeladen haben und die Fähigkeiten eines Clients bestimmen können. Aus Gründen der Zugänglichkeit und der Abwärtskompatibilität wird, wo immer möglich, auf funktionale Client-Skript-freie Funktionalität zurückgegriffen.

Ja, natürlich schreiben Sie eine eigenständige json api für diese App-Funktionalität. Aber gehen Sie nicht so weit, dass Sie eine json api für Dinge schreiben, die gut als statische html-Dokumente funktionieren.

Answer 3

REST-Server + JavaScript-lastiger Client war das Prinzip, das ich bei meiner jüngsten Arbeit verfolgt habe.

REST-Server wurde implementiert in node.js + Express + MongoDB (sehr gute schriftliche Leistung) + Mongoose ODM (ideal für die Modellierung von Daten, einschließlich Validierung) + CoffeeScript (Ich würde jetzt ES2015 stattdessen gehen), die gut für mich gearbeitet. Node.js mag im Vergleich zu anderen möglichen serverseitigen Technologien relativ jung sein, aber es ermöglichte mir, eine solide API mit integrierten Zahlungen zu schreiben.

Ich habe die Ember.js als JavaScript-Framework und der größte Teil der Anwendungslogik wurde im Browser ausgeführt. Ich habe verwendet SASS (speziell SCSS) für die CSS-Vorverarbeitung.

Ember ist ein ausgereiftes Framework, das von einer starken Gemeinschaft unterstützt wird. Es ist ein sehr leistungsfähiges Framework, an dem in letzter Zeit viel gearbeitet wurde und das sich auf die Leistung konzentriert, wie brandneue Glimmer-Rendering-Engine (inspiriert von React).

Das Ember Core Team ist dabei, eine FastBoot die es Ihnen ermöglicht, Ihre JavaScript-Ember-Logik serverseitig (speziell node.js) auszuführen und vorgerendertes HTML Ihrer Anwendung (die normalerweise im Browser ausgeführt würde) an den Benutzer zu senden. Das ist großartig für SEO und Benutzererfahrung, da er nicht so lange auf die Anzeige der Seite warten muss.

Ember CLI ist ein großartiges Werkzeug, das Ihnen hilft, Ihren Code zu organisieren, und das sich gut an die wachsende Codebasis anpassen lässt. Ember hat auch sein eigenes Addon Ökosystem und Sie können aus einer Vielzahl von Ember-Zusätze . Sie können einfach Bootstrap (in meinem Fall) oder Foundation nehmen und es zu Ihrer App hinzufügen.

Um nicht alles über Express auszuliefern, habe ich mich entschieden, nginx für die Auslieferung von Bildern und JavaScript-lastigen Clients zu verwenden. Die Verwendung von nginx proxy war in meinem Fall hilfreich:

upstream app_appName.com {
  # replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
  server 0.0.0.0:1000;
  keepalive 8;
}

server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

  client_max_body_size 32M;

  access_log  /var/log/nginx/appName.access.log;
  error_log  /var/log/nginx/appName.error.log;

  server_name appName.com appName;

  location / {
     # frontend assets path
     root /var/www/html;
     index index.html;

     # to handle Ember routing
     try_files $uri $uri/ /index.html?/$request_uri;
  }

  location /i/ {
    alias /var/i/img/;
  }

  location /api/v1/ {
    proxy_pass  http://app_appName.com;

    proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
    proxy_redirect off;
    proxy_buffering off;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Pro: Ich liebe die Trennung von API und Client. Kluge Leute sagen, dies sei der richtige Weg. Großartig in der Theorie. Scheint hochmodern und aufregend zu sein.

Ich kann sagen, dass es auch in der Praxis großartig ist. Ein weiterer Vorteil der Trennung der REST-API ist, dass man sie später für andere Anwendungen wiederverwenden kann. In einer perfekten Welt sollten Sie in der Lage sein, dieselbe REST-API nicht nur für Webseiten, sondern auch für mobile Anwendungen zu verwenden, wenn Sie sich entscheiden, eine zu schreiben.

Contra: Wenig Präzedenzfälle. Es gibt nicht viele Beispiele dafür, dass dies gut gelungen ist. Öffentliche Beispiele (twitter.com) fühlen sich träge an und gehen sogar weg von diesem Ansatz ab.

Die Dinge sehen jetzt anders aus. Es gibt viele Beispiele für eine REST-API und viele Clients, die sie nutzen.

Answer 4

Ich habe mich für die Architektur von Option 2 entschieden, weil Uniformen da es eine hervorragende Möglichkeit bot, die Benutzeroberfläche von der Geschäftslogik zu trennen.

Dies hat den Vorteil, dass die API-Server unabhängig von den Webservern skaliert werden können. Wenn Sie mehrere Kunden haben, müssen die Websites nicht in gleichem Maße skaliert werden wie die Webserver, da einige Kunden auf Telefonen/Tablets oder Desktops arbeiten.

Dieser Ansatz bietet Ihnen auch eine gute Grundlage für die Öffnung Ihrer API für Ihre Nutzer, insbesondere wenn Sie Ihre eigene API verwenden, um alle Funktionen Ihrer Website bereitzustellen.

Answer 5

Eine sehr nette Frage, und ich bin überrascht, da ich dachte, dass dies heutzutage eine sehr häufige Aufgabe ist, so dass ich viele Ressourcen für dieses Problem haben werde, aber es stellte sich heraus, dass das nicht stimmt.

Meine Gedanken sind wie folgt: - Erstellen Sie ein Modul, das die gemeinsame Logik zwischen den API-Controllern und den HTML-Controllern enthält. ohne json zurückgeben oder html rendern und dieses Modul sowohl in den HTML-Controller als auch in den API-Controller einbinden, dann tun Sie, was immer Sie wollen, also zum Beispiel

module WebAndAPICommon
    module Products

        def index
            @products = # do some logic here that will set @products variable
        end

    end
end

class ProductsController < ApplicationController
    # default products controlelr, for rendering HMTL pages 
    include WebAndAPICommon

    def index
        super
    end

end

module API
    class ProductsController
        include WebAndAPICommon

        def index
            super
            render json: @products
        end

    end
end