Séparer le serveur D'API REST JSON du client? [fermé]

je suis sur le point de créer un tas d'applications web à partir de zéro. (Voir http://50pop.com/code pour vue d'ensemble. J'aimerais qu'ils soient accessibles à partir de nombreux clients différents: sites web front-end, applications pour smartphones, serveurs web backend, etc. Donc je veux vraiment une API de repos JSON pour chacun d'eux.

aussi, je préfère travailler sur le back-end, donc je rêve de garder mon attention purement sur L'API, et engager quelqu'un d'autre pour faire le front-end UI, que ce soit un site web, iPhone, Android, ou autre application.

s'il vous plaît aidez-moi à décider quelle approche je dois adopter:

ENSEMBLE SUR RAILS

font un très standard Rails Web-app. Dans le controller, faites le commutateur respond_with, pour servir soit JSON, soit HTML. La réponse JSON est alors mon API.

Pro: Beaucoup de précédents. Grande normes & de nombreux exemples de faire les choses de cette façon.

Con: Ne veut pas nécessairement l'API de même que la web app. Ne pas aimer Si / puis répondre avec l'approche de commutateur. Mélange de deux choses très différentes (UI + API).

REST SERVER + JAVASCRIPT-HEAVY CLIENT

crée un serveur D'API REST JSON-only. Utilisez la colonne vertébrale ou la braise.js côté client JavaScript pour accéder directement l'API, de l'affichage modèles dans le navigateur.

Pro: j'aime la séparation de l'API et du client. Les gens intelligents disent que c'est la voie à suivre. Bien en théorie. Semble de pointe et passionnant.

Con: peu de précédents. Pas beaucoup d'exemples de ce fait. Exemples publics (twitter.com) se sentent léthargiques et se détournent même de cette approche.

SERVEUR DE REPOS + CLIENT HTML CÔTÉ SERVEUR

crée un serveur D'API REST JSON-only. Créer un client de site Web HTML de base, qui accède à L'API REST uniquement. Moins de JavaScript côté client.

Pro: j'aime la séparation de l'API et du client. Mais servir du HTML5 ordinaire est tout à fait infaillible et n'exige pas beaucoup de clients.

Con: peu de précédents. Pas beaucoup d'exemples de ce fait. Les cadres ne supportent pas cette ainsi. Vous ne savez pas comment l'aborder.

particulièrement à la recherche de conseils à partir de l'expérience, pas seulement en théorie.

370
demandé sur sivers 2012-06-08 03:27:56
la source

18 ответов

à Boundless , nous sommes allés plus loin avec l'option #2 et l'avons déployée à des milliers d'étudiants. Notre serveur est une API JSON REST (Scala + MongoDB), et tout notre code client est servi directement depuis CloudFront (i.e.: www.boundless.com est juste un alias pour CloudFront).

Pour:

  • Cutting-edge / exciting
  • beaucoup de bang pour votre buck: L'API vous donne la base pour votre propre client web, clients mobiles, accès tiers,etc.
  • excessivement chargement rapide du site / transitions de page

Inconvénients:

  • Pas SEO friendly/prêt, sans beaucoup plus de travail.
  • nécessite des gens haut de gamme de première ligne Web qui sont prêts à faire face à la réalité d'un site expérience qui est de 70% javascript et ce que cela signifie.

je crois que cette

nous avons construit un harnais pour notre développement frontal appelé "Spar" (Single Page App Rocketship) qui est en fait le pipeline de l'actif de Rails accordé pour le développement d'une page app. Nous serons sur notre page GitHub , ainsi qu'un billet de blog expliquant comment l'utiliser et l'architecture globale plus en détail.

mise à jour:

en ce qui concerne les préoccupations des Épine dorsale, je pense qu'ils sont surévalués. L'ossature est bien plus un principe d'organisation qu'un cadre profond. Le site de Twitter lui-même est une bête géante de Javascript couvrant tous les coins de rue à travers des millions d'utilisateurs et navigateurs hérités, tout en chargeant des tweets en temps réel, collecte des ordures, afficher beaucoup de multimédia, etc. De tous les sites "purs" js que J'ai vu, Twitter est le plus bizarre. Il y a eu beaucoup d'applications remarquablement compliquées livrées via JS qui fonctionnent très bien.

et votre choix d'architecture dépend entièrement de vos objectifs. Si vous êtes à la recherche du moyen le plus rapide pour prendre en charge plusieurs clients et avoir accès à de bons talents initiaux, investir dans une API autonome est une excellente façon de procéder.

133
répondu Aaron 2013-02-25 16:51:26
la source

très bien demandé. +1. Pour sûr, c'est l'avenir de référence utile pour moi. Aussi @ Aaron et d'autres ont ajouté de la valeur à la discussion. Comme Ruby, cette question est également applicable à d'autres environnements de programmation.

j'ai utilisé les deux premières options. Le premier pour de nombreuses applications et le deuxième pour mon projet open source Cowoop

Option 1

celui-ci est sans doute le le plus populaire. Mais je trouve que l'implémentation est très http-ish. Le code initial de chaque API va dans le traitement de l'objet de la requête. Donc le code API est plus que du ruby pur / python / autre code de langue.

Option 2

j'ai toujours aimé ça.

cette option implique également que HTML n'est pas généré sur le serveur. C'est pourquoi l'option 2 est différente de l'option 3. Mais sont construits en html statique utiliser un script de construction. Une fois chargé du côté client, ce HTML appellerait le serveur API comme client API JS.

  • la séparation des préoccupations est un grand avantage. Et très bien à votre goût (et à la mienne) les experts backend implémentent les API backend, les testent facilement comme le code de langage habituel sans se soucier du code de requête framework/ http.

  • ce n'est vraiment pas aussi difficile que cela sonne du côté de frontend. Faire Les appels API et les données résultantes (principalement json) sont disponibles pour votre modèle côté client ou MVC.

  • moins de traitement côté serveur. Cela signifie que vous pouvez aller pour le matériel de base / Serveur moins cher.

  • plus facile de tester les couches indépendamment, plus facile de générer des documents API.

il a quelques inconvénients.

  • beaucoup de développeurs trouvent cela sur Conçu et difficile à comprendre. Il y a donc des chances que l'architecture soit critiquée.

  • i18n/l10n est dur. Puisque HTML est essentiellement généré, le temps de compilation est statique, il faut plusieurs compilations par langage pris en charge (ce qui n'est pas nécessairement une mauvaise chose). Mais même avec cela, vous pouvez avoir des cas de coin autour de l10n/i18n et ont besoin d'être prudent.

Option 3

Le codage

dans ce cas doit être identique à la deuxième option. La plupart des points pour l'option 2 s'appliquent ici aussi.

les pages Web sont rendues exécutables en utilisant des gabarits côté serveur. Cela rend i18n/l10n beaucoup plus facile avec des techniques plus établies/acceptées. Peut - être un appel http de moins pour un contexte essentiel nécessaire au rendu de page comme l'utilisateur, la langue, la devise, etc. Donc le traitement côté serveur est augmenté avec le rendu mais éventuellement compensé par moins d'appels http vers le serveur API.

maintenant que les pages sont des serveurs rendus sur le serveur, frontend est maintenant plus lié avec l'environnement de programmation. Ce n'est peut-être même pas une considération pour de nombreuses demandes.

Twitter "cas 1519610920"

comme je le comprends, Twitter pourrait faire leur page initiale de rendu sur le serveur, mais pour les mises à jour de page il a encore quelques appels API et le client les gabarits de côté pour manipuler le DOM. Donc, dans un tel cas, vous avez Double gabarits à maintenir qui ajoute un peu de frais généraux et de complexité. Tout le monde ne peut pas se permettre cette option, contrairement à Twitter.

notre pile de projets

il se trouve que J'utilise Python. J'utilise JsonRPC 2.0 au lieu de repos. Je suggère le repos, bien que j'aime l'idée de JsonRPC pour diverses raisons. J'utilise ci-dessous les bibliothèques. Quelqu'un envisageant l'option 2/3 pourrait la trouver utile.

ma conclusion et recommandation

Option 3!.

tout dit, j'ai utilisé l'option 2 avec succès mais maintenant penchant vers l'option 3 pour une certaine simplicité. Générer des pages HTML statiques avec le script de construction et les servir avec l'un des serveurs ultra rapide qui se spécialisent dans le service des pages statiques est très tentant (Option 2).

48
répondu Shekhar 2015-01-20 03:12:37
la source

nous avons opté pour le N ° 2 lors de la construction de gaug.es. J'ai travaillé sur L'API (ruby, sinatra, etc.) et mon partenaire commercial, Steve Smith, a travaillé sur le front-end (client javascript).

Pour:

  1. se déplacent rapidement en parallèle. Si je travaillais avant Steve, je pourrais continuer à créer des API pour de nouvelles fonctionnalités. S'il travaillait avant moi, il pourrait simuler l'API très facilement et construire L'UI.

  2. API gratuitement. Avoir un accès libre aux données de votre application devient rapidement une caractéristique standard. Si vous commencez avec une API à partir de la base, vous l'obtenez gratuitement.

  3. Propre séparation. Il est préférable de penser à votre application comme une API avec des clients. Bien sûr, le premier et le plus important client peut être un web one, mais il vous met en place pour créer facilement d'autres clients (iPhone, Android).

Inconvénients:

  1. Rétrocompatibilité. C'est plus lié à une API qu'à votre question directe, mais une fois que votre API est disponible, vous ne pouvez pas la casser ou vous cassez tous vos clients deux. Cela ne signifie pas que vous devez vous déplacer plus lentement, mais cela signifie que vous devez souvent faire fonctionner deux choses à la fois. Ajouter à L'API ou de nouveaux champs est très bien, mais changer/supprimer ne devrait pas être fait sans versioning.

Je ne peux plus penser à des escrocs en ce moment.

Conclusion: le client API + JS est la voie à suivre si vous prévoyez de libérer une API.

P.S. Je recommande également de documenter complètement votre API avant de la libérer. Le processus de documentation Gaug.es API nous a vraiment aidés imp

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

28
répondu John Nunemaker 2012-06-12 05:03:00
la source

je préfère suivre la route des numéros 2 et 3. Principalement parce que #1 viole la séparation des préoccupations et mélange toutes sortes de choses. Finalement, vous trouverez le besoin d'avoir un point D'extrémité D'API qui n'a pas une page HTML/etc correspondant et vous serez dans un ruisseau avec des points D'extrémité HTML et JSON entremêlés dans la même base de code. Il se transforme en un foutoir, même si son MVP, vous aurez à réécrire éventuellement parce que son soo désordre que son même pas la peine de sauver.

aller avec #2 ou #3 vous permet d'avoir complètement une API qui agit de la même manière (pour la plupart) indépendamment. Cela offre une grande flexibilité. Je ne suis pas vendu à 100% Sur Backbone/ember/whatever/etc.js pour l'instant. Je pense que son grand, mais comme nous le voyons avec twitter, ce n'est pas optimal. MAIS... Twitter est aussi une énorme bête de compagnie et compte des centaines de millions d'utilisateurs. Ainsi, toute amélioration peut avoir un impact énorme sur les résultats financiers de divers secteurs d'activités. Je pense qu'il est plus à la décision que la vitesse seul et ils ne vont pas nous laisser entrer. Mais c'est juste mon avis. Toutefois, Je ne réduis pas backbone et ses concurrents. Ces applications sont grands à utiliser et sont très propres et très à l'écoute (pour la plupart).

la troisième option a aussi une allure valide. C'est là que je suivrais le principe de Pareto (règle 80/20) et que j'aurais 20% de votre markup principal (ou vice versa) rendu sur le serveur et que j'aurais ensuite un joli client JS (backbone/etc) exécuter le reste. Vous ne communiquerez peut-être pas 100% avec L'api REST via le client JS, mais vous ferez un peu de travail si nécessaire pour améliorer l'expérience suer.

je pense que c'est l'un de ces types de problèmes" cela dépend "et la réponse est" cela dépend " de ce que vous faites, qui vous servez et quel type d'expérience vous voulez qu'ils reçoivent. Étant donné que je pense que vous pouvez choisir entre 2 ou 3 ou un hybride.

10
répondu Donn Felker 2012-06-08 03:53:03
la source

je travaille actuellement sur la conversion d'un énorme CMS de l'option 1 à l'option 3, et ça se passe bien. Nous avons choisi de rendre le markup côté serveur parce que le référencement est important pour nous, et nous voulons que les sites fonctionnent bien sur les téléphones mobiles.

j'utilise node.js pour le client back-end et une poignée de modules de m'aider. Je suis un peu au début du processus, mais le fondement est établi et il s'agit de passer en revue les données pour s'assurer que tout se passe bien. Voici ce que J'utilise:

  • Express pour l'application de la fondation.

    (https://github.com/visionmedia/express)
  • demande pour récupérer les données.

    (https://github.com/mikeal/request)
  • souligne les gabarits qui sont rendus côté serveur. Je les réutilise sur le client.

    (https://github.com/documentcloud/underscore)
  • utml wraps underscore des modèles pour les faire fonctionner avec Express.

    (https://github.com/mikefrey/utml)
  • collecte à L'avance des modèles et nous allons choisir qui sont envoyés au client.

    (https://github.com/mrDarcyMurphy/upfront)
  • Express Expose passe les données récupérées, certains modules, et les gabarits au front-end.

    (https://github.com/visionmedia/express-expose)
  • colonne vertébrale crée des modèles et des vues sur le devant après avoir avalé les données qui ont été transmises.

    (https://github.com/documentcloud/backbone)

C'est le cœur de la pile. Quelques autres modules que j'ai trouvé utiles:

  • fleck (https//github.com / trek / fleck)
  • moment (https / / github.com / timrwood / moment)
  • stylet (https//github.com/LearnBoost/stylet)
  • smoosh (https//github.com / fat/ smoosh)

    ... bien que j'enquête sur grunt (https//github.com / cowboy / grunt)
  • trace de la console (//github.com/LearnBoost/console-trace).

Non, Je n'utilise pas coffeescript.

Cette option fonctionne vraiment bien pour moi. Les modèles du back-end n'existent pas parce que les données que nous obtenons de L'API sont bien structurées et je les passe verbatim pour le front-end. La seule exception est notre maquette où j'ajoute un attribut unique qui rend le rendu plus intelligent et plus léger. Je n'ai pas utilisé de bibliothèque de modèles sophistiquée pour cela, juste une fonction qui ajoute ce dont j'ai besoin sur l'initialisation et qui retourne elle-même.

(désolé pour le bizarre liens, je suis trop un n00b de débordement de pile de me laisser poster tant que ça)

7
répondu Darcy Murphy 2012-06-08 14:28:44
la source

Nous utilisons la variante suivante de #3: Créer un serveur D'API REST JSON-only. Créer un serveur de site Web HTML. Le serveur web HTML n'est pas, comme dans votre variante, un client du serveur D'API REST. Au lieu de cela, les deux sont pairs. Non loin sous la surface, il y a une API interne qui fournit les fonctionnalités dont les deux serveurs ont besoin.

nous ne connaissons aucun précédent, donc c'est un peu expérimental. Jusqu'à présent (sur le point d'entrer en bêta), il a travaillé assez bien.

7
répondu Thomas Becker 2012-06-14 22:16:47
la source

je vais généralement pour la 2e option, en utilisant des Rails pour construire L'API, et l'épine dorsale pour les trucs JS. Vous pouvez même obtenir gratuitement un panneau d'administration en utilisant ActiveAdmin . J'ai envoyé des dizaines d'applications mobiles avec ce genre de backend. Cependant, cela dépend fortement si votre application est interactive ou non.

j'ai fait une présentation sur cette approche au dernier RubyDay.it : http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

Pour la troisième option, afin d'obtenir la réactivité de la 2ème, vous pourriez vouloir essayer pajax comme Github.

7
répondu Matteo Collina 2012-06-21 17:16:58
la source

je suis environ 2 mois dans un projet de 3 mois qui prend la deuxième approche que vous avez décrite ici. Nous utilisons un serveur API RESTful côté avec de la colonne vertébrale.js sur le devant. Guidon.js gère les gabarits et jQuery gère les manipulations AJAX et DOM. Pour les navigateurs plus anciens et les araignées de recherche, nous sommes retombés dans le rendu côté serveur, mais nous utilisons les mêmes modèles HTML que le guidon frontend en utilisant Mozilla Rhino.

nous avons choisi cette approche pour plusieurs différentes raisons mais sont très conscients que c'est un peu risqué étant donné qu'il n'a pas encore été prouvé à grande échelle. Tous les te même, tout va assez bien jusqu'à présent.

jusqu'à présent, nous n'avons travaillé qu'avec une API, mais dans la prochaine phase du projet, nous allons travailler avec une seconde API. La première est pour de grandes quantités de données, et la seconde agit plus comme un CMS via une API.

ayant ces deux pièces du projet agir complètement indépendant de chaque un autre facteur a joué un rôle clé dans le choix de cette infrastructure. Si vous êtes à la recherche d'une architecture pour mashup différentes ressources indépendantes sans aucune dépendance, alors cette approche vaut le coup d'oeil.

je crains de ne pas être un type de Ruby donc je ne peux pas commenter les autres approches. Parfois, il est bon de prendre un risque. D'autres fois, il est préférable de jouer la sécurité. Vous vous découvrirez en fonction du type de projet.

bonne chance avec votre choix ici. Hâte de voir ce que les autres partagent.

6
répondu Iarfhlaith Kelly 2012-06-08 03:57:31
la source

j'aime #3 Quand mon site web ne va pas être une implémentation 100% CRUD de mes données. Qui n'est pas encore arriver.

je préfère sinatra et juste à diviser l'application en quelques rack applications avec des buts différents. Je vais créer une application rack spécifique à L'API qui couvrira ce dont j'ai besoin pour L'API. Alors peut-être une application de rack utilisateur qui présentera ma page web. Parfois, cette version interrogera L'API si nécessaire, mais en général, elle ne concerne que le site html.

Je ne m'inquiète pas à ce sujet et il suffit de faire une requête de couche de persistance du côté de l'utilisateur si j'en ai besoin. Je ne suis pas trop soucieux de créer une séparation complète car ils finissent généralement par servir des buts différents.

voici un très exemple simple d'utilisation de plusieurs applications rack. J'ai ajouté un exemple de jQuery rapide pour que vous le voyiez frapper l'application API. Vous pouvez voir comment simple il peut être avec sinatra et le montage multiple rack applications avec des buts différents.

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

4
répondu Dusty 2012-06-08 05:47:04
la source

quelques bonnes réponses ici déjà-je recommanderais certainement #2 ou #3 - la séparation est bonne conceptuellement mais aussi dans la pratique.

il peut être difficile de prédire des choses comme la charge et les modèles de trafic sur une API et les clients que nous voyons qui servent l'API indépendamment ont un temps plus facile de provision et de mise à l'échelle. Si vous devez faire cela munged dedans avec des modèles d'accès de web humain c'est moins facile. En outre, votre utilisation de L'API pourrait finir par passer à l'échelle beaucoup plus rapidement que votre web client et vous pouvez voir où diriger vos efforts.

entre #2 #3 Cela dépend vraiment de vos objectifs - je suis d'accord que #2 est probablement l'avenir de webapps - mais peut-être que vous voulez quelque chose de plus simple si cette chaîne va être seulement l'un des nombreux!

1
répondu steve 2012-06-08 15:13:45
la source

pour votre service.com.cy nous utilisons des modèles rendus côté serveur pour les pages spécialement pour couvrir la partie se. Et l'utilisation de L'API pour les interactions après le chargement de la page. Comme notre framework est MVC, toutes les fonctions du contrôleur sont dupliquées à la sortie JSON et à la sortie html. Les gabarits sont propres et reçoivent juste un objet. Cela peut être transformé en js templates en quelques secondes. Nous maintenons toujours les modèles serverside et reconvertissons simplement à js sur demande.

1
répondu xatzistnr 2014-03-08 16:29:15
la source

Rendu isomorphe et amélioration progressive. C'est ce que je pense que vous alliez faire dans l'option 3.

Rendu isomorphe signifie utiliser le même modèle pour générer le markup Côté Serveur que vous utilisez dans le code côté client. Choisissez un langage de templating avec de bonnes implémentations côté serveur et côté client. Créez du html entièrement cuit pour vos utilisateurs et envoyez-le sur le fil. Utiliser la mise en cache.

amélioration progressive signifie commencer à faire l'exécution côté client et le rendu et l'écoute des événements une fois que vous avez toutes les ressources téléchargées et vous pouvez déterminer les capacités d'un client. Revenir à la fonctionnalité client-script-moins de fonctionnalité dans la mesure du possible pour l'accessibilité et la compatibilité ascendante.

Oui, bien sûr, écrivez une api JSON autonome pour cette fonctionnalité de l'application. Mais n'allez pas jusqu'à écrire une api json pour des choses qui fonctionne très bien en tant que documents statiques html.

1
répondu sirtimbly 2015-06-06 11:10:34
la source

REST server + JavaScript-heavy client était le principe que j'ai suivi dans mes récents travaux.

REST server a été implémenté dans le noeud .js + Express + MongoDB (très bonne performance d'écriture) + Mongoose ODM (grand pour la modélisation des données, validations incluses) + CoffeeScript (j'irais ES2015 maintenant à la place) qui a bien fonctionné pour moi. Nœud.js peut-être relativement jeune par rapport à d'autres technologies possibles côté serveur, mais il m'a permis d'écrire API solide avec des paiements intégrés.

j'ai utilisé Ember.js comme JavaScript framework et la plupart de la logique de l'application a été exécutée dans le navigateur. J'ai utilisé SASS (SCSS spécifiquement) pour le prétraitement CSS.

Braise est mature cadre soutenu par une forte communauté. Il est très cadre puissant avec beaucoup de travail en cours récemment mis l'accent sur la performance, comme tout nouveau moteur de rendu Glimmer (inspiré par React).

Ember Core Team est en train de développer FastBoot , qui vous permettent d'exécuter votre logique Ember JavaScript côté serveur (noeud.js spécifiquement) et envoyer le HTML pré-rendu de votre application (qui serait normalement exécuté dans le navigateur) à l'utilisateur. Il est idéal pour le SEO et l'utilisateur de l'expérience comme il n'a pas d'attendre si longtemps pour que la page soit affichée.

Ember clip est un excellent outil qui vous aide à organiser votre code et il a bien fait à l'échelle avec croissance codebase. Ember a également son propre écosystème addon et vous pouvez choisir parmi la variété de Ember Addons . Vous pouvez facilement saisir Bootstrap (dans mon cas) ou Fondation et l'ajouter à votre application.

pas pour tout servir Via Express, j'ai choisi pour utiliser nginx pour servir des images et JavaScript-client lourd. L'utilisation de Nginx proxy a été utile dans mon cas:

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": j'adore la séparation de l'API et du client. Les gens intelligents disent que c'est le chemin à parcourir. Bien en théorie. Semble de pointe et passionnant.

je peux dire que c'est aussi génial dans la pratique. Un autre avantage de séparer L'API REST est que vous pouvez la réutiliser plus tard pour d'autres applications. En parfait world vous devriez être en mesure d'utiliser la même API REST non seulement pour la page Web, mais aussi pour les applications mobiles Si vous décidez d'en écrire une.

Con: peu de précédents. Pas beaucoup d'exemples de ce fait. Public exemples (twitter.com) se sentent léthargiques et s'éloignent même de cette approche.

les choses semblent différentes maintenant. Il ya beaucoup d'exemples de faire REST API + de nombreux clients le consommant.

1
répondu Daniel Kmak 2015-09-27 17:25:27
la source

j'ai décidé d'opter pour l'architecture de L'Option #2 pour Infiniforms , car elle offrait un excellent moyen de séparer L'UI de la logique d'entreprise.

un avantage de ceci est que les serveurs API peuvent être dimensionnés indépendamment des serveurs web. Si vous avez plusieurs clients, alors les sites Web n'auront pas besoin d'être mis à l'échelle dans la même mesure que les serveurs web, car certains clients seront basés sur téléphone / tablette ou bureau.

This approach vous donne également une bonne base pour ouvrir votre API à vos utilisateurs, surtout si vous utilisez votre propre API pour fournir toutes les fonctionnalités pour votre site web.

1
répondu Karl Gjertsen 2016-06-06 10:44:07
la source

une très belle question et je suis surpris car j'ai pensé que c'est une tâche très commune de nos jours tels que je vais avoir beaucoup de ressources pour ce problème, mais s'est avéré ne pas être vrai.

mes pensées sont les suivantes: - Créer un certain module qui ont la logique commune entre les contrôleurs API et les contrôleurs HTML sans de retour json ou de rendu html, et inclure ce module dans le contrôleur HTML et le contrôleur API, puis faire tout ce que vous voulez, par exemple:

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
1
répondu Loai Ghoraba 2016-07-06 16:54:23
la source

j'ai opté pour une approche hybride où nous utilisons Sinatra comme base, ActiveRecord / Postgress etc pour servir des routes de page (modèles slim) exposer une API REST que le Web-app peut utiliser. Au début du développement, par exemple, la saisie des options select est effectuée par l'intermédiaire des helpers du rendu dans le modèle slim, mais à mesure que nous approchons de la production, cela est remplacé par un appel AJAX vers une API REST, car nous commençons à nous soucier davantage de la vitesse de chargement de la page et ainsi de suite.

C'est facile rendre dans Slim est manipulé de cette façon, et stuff (peupler des formes, recevoir des données de post de forme de jQuery.Validation submitHandler etc, est tout abviously AJAX)

Le test

est un problème. En ce moment je suis stumped essayer de passer des données JSON à un Rack::test POST test .

0
répondu Dave Sag 2017-05-23 15:26:43
la source

personnellement, je préfère l'option (3) comme solution. Il est utilisé dans presque tous les sites qu'un ancien (nom du ménage) employeur de la mine A. Cela signifie que vous pouvez obtenir quelques devs front-end qui savent tout au sujet de Javascript, bizarreries de navigateur et autres pour coder votre front-end. Ils ont seulement besoin de savoir "curl xyz et vous obtiendrez quelques json" et ils s'en vont.

pendant ce temps, vos gars lourds de derrière peuvent coder les fournisseurs Json. Ces gars n'ont pas besoin de penser la présentation du tout, et au lieu de s'inquiéter des retours en arrière, timeouts, manipulation gracieuse d'erreur, piscines de connexion de base de données, filetage, et mise à l'échelle, etc.

L'option 3 vous offre une architecture solide à trois niveaux. Cela signifie que les choses que vous crachez de l'avant est SEO friendly, peut être fait pour travailler avec de vieux ou de nouveaux navigateurs (et ceux avec JS éteint), et pourrait encore être JavaScript client-côté Templier si vous voulez (afin que vous puissiez faire des choses comme Gérer Vieux navigateurs / googlebot avec HTML statique, mais envoyer js construit des expériences dynamiques pour les gens en utilisant le dernier navigateur Chrome ou autre).

dans tous les cas que j'ai vu L'Option 3, il a été une mise en œuvre personnalisée de certains PHP qui n'est pas particulièrement transférable entre les projets, et encore moins à L'extérieur de la terre en Open Source. Je suppose que plus récemment PHP peut avoir été remplacé par Ruby / Rails, mais le même genre de chose est toujours vrai.

151900920 FWIW, $current_employerer could faites avec L'Option 3 dans quelques endroits importants. Je cherche un cadre en rubis dans lequel construire quelque chose. Je suis sûr que je peux coller une charge de pierres précieuses, mais je préférerais un seul produit qui fournit largement une solution de cache connecté à memcache/nosql, de type Templier, 'curling', d'authentification optionnelle. Là, Je ne trouve rien de cohérent: - (

0
répondu Ralph Bolton 2013-12-02 14:37:10
la source

la construction D'une API JSON dans les Rails est de première classe, le JSONAPI:: ressources gem fait le levage lourd pour un http://jsonapi.org API spec'D.

0
répondu pixelhandler 2017-01-07 20:29:31
la source