De REPOS séparée JSON API serveur et le client?

Question

Je suis sur le point de créer un tas d'apps web à partir de zéro. (Voir http://50pop.com/code pour la vue d'ensemble). Je voudrais pour eux d'être en mesure d'être accessible à partir de nombreux clients différents: front-end des sites web, des applications pour smartphone, backend webservices, etc. Donc j'ai vraiment envie d'un JSON API REST pour chacun.

Aussi, je préfère travailler sur le back-end, donc je rêve de me garder mes se concentrer uniquement sur l'API, et l'embauche de quelqu'un d'autre pour faire de la face avant de l'INTERFACE utilisateur, que ce soit un site web, iPhone, Android, l'application ou d'autres.

S'il vous plaît aidez-moi à décider de l'approche que je dois prendre:

ENSEMBLE DE RAILS

Faire un très standard Rails de la web-app. Dans le contrôleur, ne le respond_with interrupteur, pour servir de format JSON ou HTML. La réponse JSON est alors mon API.

Pro: Beaucoup de précédents. De grands standards et 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. N'est pas comme si/alors respond_with commutateur approche. Le mélange de deux choses très différentes (UI + API).

RESTE SERVEUR + JAVASCRIPT-LOURDS CLIENT

Faire un JSON-seulement le REPOS de l'API serveur. L'utilisation de la Dorsale ou Ember.js pour le JavaScript côté client pour accéder directement l'API, l'affichage de modèles dans le navigateur.

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

Con: Pas beaucoup de précédents. Pas beaucoup d'exemples de ce fait. Public exemples (twitter.com) sentir léthargique et sont même en s'éloignant de cette approche.

RESTE + SERVEUR SERVEUR HTML CÔTÉ CLIENT

Faire un JSON-seulement le REPOS de l'API serveur. Faire une base de site HTML au client, qui accède à l'API REST. Moins de JavaScript côté client.

Pro: j'aime la séparation de l'API et du client. Mais la portion de la plaine HTML5 est assez infaillible et pas de client-intensif.

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

Particulièrement à la recherche pour obtenir des conseils de l'expérience, et pas seulement en théorie.

Answer 1

À l' Infini, nous avons examiné en profondeur avec l'option #2 et laminés à des milliers d'étudiants. Notre serveur est un JSON API REST (Scala + MongoDB), et l'ensemble de notre code client est servi tout droit sorti de CloudFront (c'est à dire: www.boundless.com est juste un alias pour CloudFront).

Pour:

• Coupe-bordure/excitant
• Beaucoup de bang pour votre buck: API vous donne la base pour votre propre client web, les clients mobiles, 3e partie accès, etc.
• extrêmement rapide de chargement du site / transitions de page

Inconvénients:

• Pas SEO friendly/prêt, sans beaucoup plus de travail.
• Nécessite des top-notch web front-end folklorique qui sont prêts à faire face w/ la réalité de l'expérience du site qui est de 70% de javascript et de ce que cela signifie.

Je pense que c'est l'avenir de tous les web-apps.

Quelques pensées pour le web front-end les gens (qui est l'endroit où tous les nouveau-ness/défi est compte tenu de cette architecture):

• CoffeeScript. Beaucoup plus facile de produire de haute qualité de code.
• De la colonne vertébrale. Excellente façon d'organiser votre logique, et d'une communauté active.
• HAMLC. Haml + CoffeeScript templates => JS.
• SASS

Nous avons construit un harnais pour notre front-end développement appelé "Spar' " (Single Page App Rocketship) qui est effectivement l'asset pipeline de Rails à l'écoute pour de single page app de développement. Nous allons être open-source dans les deux prochaines semaines sur notre github page, le long avec un billet de blog expliquant comment l'utiliser et de l'ensemble de l'architecture dans le plus grand détail.

Mise à JOUR:

À l'égard des préoccupations du peuple avec la Dorsale, je pense qu'ils sont sur-évalué. La dorsale est beaucoup plus un principe organisationnel que c'est une profonde cadre. Twitter du site lui-même est une bête immense de Javascript couvrant tous les coins de cas, à travers des millions d'utilisateurs et d'anciens navigateurs, lors du chargement des tweets en temps réel, des ordures, de recueillir, d'afficher beaucoup de multimédia, etc. De tous les "pure" js les sites que j'ai vu, Twitter est le plus étrange. Il y a eu beaucoup de façon impressionnante compliqué applications livrées via JS ce tarif très bien.

Et votre choix de l'architecture dépend de vos objectifs. Si vous cherchez le moyen le plus rapide pour prendre en charge plusieurs clients et d'avoir accès à une bonne avant la fin de talent, d'investir dans une application autonome d'API est un excellent moyen d'aller.

Answer 2

Très bien posée. +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 le Rubis, cette question est également applicable à d'autres environnements de programmation.

J'ai utilisé les deux premières options. Premier pour de nombreuses applications, et un deuxième pour mon projet open source Cowoop

Option 1

Celui-ci est sans aucun doute le plus populaire. Mais je trouve que la mise en œuvre sont très bien http-ish. Chaque API code initial va dans le traitement avec la demande de l'objet. Donc le code API est plus qu'un pur ruby/python/autre code de langue.

Option 2

J'ai toujours aimé cela.

Cette option implique également que le HTML n'est pas d'exécution généré sur le serveur. C'est de cette façon l'option 2 est différent de l'option 3. Mais construire du html statique à l'aide d'un script de compilation. Lorsqu'il est chargé sur côté client en HTML serait d'appel de l'API serveur comme API JS client.

• La séparation des préoccupations est un grand avantage. Et beaucoup à votre goût (et le mien) backend experts en œuvre backend Api, les tester facilement comme d'habitude, le code de langue sans se soucier de cadre/ http code de la demande.

• Ce n'est vraiment pas aussi difficile qu'il y paraît sur le frontend côté. Faire des appels d'API et les données qui en résultent (surtout json) est à la disposition de votre côté client ou de modèle de MVC.

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

• Plus facile à tester les couches de façon indépendante, plus facile à générer des docs de l'API.

Elle a quelques inconvénients.

• De nombreux développeurs de ce cours, conçu et difficile à comprendre. Si les chances sont que l'architecture peut obtenir critiqué.

• i18n/l10n est dur. Depuis le HTML est essentiellement généré le temps de construction sont statiques, on a besoin de plusieurs builds chaque langue prise en charge (ce qui n'est pas nécessairement une mauvaise chose). Mais même avec que vous pourriez avoir en cas de coin autour l10n/i18n et la nécessité d'être prudent.

Option 3

Backend de codage dans ce cas doit être la même que la deuxième option. Plus de points pour l'option 2 sont également applicables ici.

Les pages Web sont rendus d'exécution côté serveur à l'aide de modèles. Cela rend i18n/l10n beaucoup plus facile avec plus de place/techniques reconnues. Peut-être un de moins http appel pour l'essentiel le contexte nécessaire pour le rendu des pages comme l'utilisateur, la langue, la monnaie, etc. Donc côté serveur de traitement est augmenté avec le rendu mais peut-être compensé par moins http appels à l'API du serveur.

Maintenant que les pages des serveurs sont rendus sur le serveur, le frontend est désormais plus liée avec l'environnement de programmation. Cela pourrait ne pas être encore une considération pour de nombreuses applications.

Twitter cas

Ce que je comprends, Twitter n'initiale du rendu d'une page sur le serveur, mais pour les mises à jour de page encore, elle a même des appels d'API côté client et des modèles pour manipuler le DOM. Donc, dans ce cas, vous avez le double de modèles, afin de maintenir ce qui ajoute des coûts et de la complexité. Pas tout le monde est Twitter pour se permettre cela.

Notre projet de Pile

Il m'arrive d'utiliser Python. J'utilise JsonRPC 2.0 au lieu de REPOS. Je suggère de REPOS, bien que j'aime l'idée de JsonRPC pour diverses raisons. J'utilise ci-dessous les bibliothèques. Quelqu'un considérant option 2/3 trouverez peut-être utile.

• API Serveur: Python Un web rapide micro framework - Flacon
• Interface serveur: Nginx
• Côté Client MVC: Knockout.js
• D'autres outils pertinents/libs:
  • Jquery
  • Accounting.js pour l'argent de la monnaie
  • Webshim : navigateur Croix de polyfill
  • directeur: côté Client de routage
  • sphc: génération HTML

Ma conclusion et recommandation

Option 3!.

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

Answer 3

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 d'affaires, Steve Smith, a travaillé sur le front-end (javascript client).

Pour:

1. Se déplacer rapidement en parallèle. Si j'ai travaillé à l'avance de Steve, j'ai pu continuer à créer des Api pour les nouvelles fonctionnalités. Si il a travaillé en avant de moi, il pouvait faire semblant de l'API très facilement et de construire l'INTERFACE utilisateur.

2. API gratuitement. En ayant accès aux données dans votre application est rapidement devenu une caractéristique standard. Si vous commencez avec un API de la base, vous obtenez ce pour gratuit.

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

Inconvénients:

1. Rétro-Compatibilité. C'est plus lié à une API que votre question directe, mais une fois que votre API est là-bas, vous ne pouvez pas briser ou vous briser tous vos clients deux. Cela ne signifie pas que vous devez vous déplacer plus lentement, mais ça ne signifie pas que vous avez à faire souvent deux à la fois. Ajoutant à l'API ou de nouveaux champs est très bien, mais la modification/suppression ne devrait pas être fait sans le contrôle de version.

Je ne pense pas plus cons maintenant.

Conclusion: + API JS client est la voie à suivre si vous envisagez sur la publication d'une API.

P. S. je vous recommande aussi pleinement documenter votre API avant de le relâcher. Le processus de documentation Gaug.es API nous a vraiment aidés imp

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

Answer 4

Je préfère suivre la voie de #2 et #3. Principalement parce que #1 viole la séparation des préoccupations et s'accorde avec toutes sortes de choses. Finalement, vous trouverez la nécessité de disposer d'une API point de fin qui ne correspond pas de page HTML/etc, et vous serez un ruisseau avec mêlé HTML et JSON points de terminaison dans la même base de code. Il se transforme en une vraie pagaille, même si son titre de MVP, vous aurez à le ré-écrire, éventuellement, parce que sa soo désordre que son même pas la peine d'être sauvé.

Va avec #2 ou #3 permet de disposer d'un API qui agit de la même manière (pour la plupart), peu importe. Cela permet une grande flexibilité. Je ne suis pas 100% vendus sur Backbone/ember/whatever/etc.js juste encore. Je pense que son grand, mais comme nous le voyons avec twitter, ce n'est pas optimal. MAIS... Twitter est aussi un énorme bête d'une entreprise et a des centaines de millions d'utilisateurs. De sorte que toute amélioration peut avoir un impact énorme à bas de ligne sur les différents domaines de différentes unités d'affaires. Je pense qu'il est plus à la décision de la vitesse de déplacement seul et ils ne vont pas nous laisser entrer. Mais c'est juste mon avis. Cependant, je n'ai pas de réduction de la dorsale et de ses concurrents. Ces applications sont grands à utiliser et sont très propres et très à l'écoute (pour la plupart).

La troisième option est valide allure. C'est là que j'aimerais suivre le principe de Pareto (80/20 règle) et d'avoir 20% de votre principal balisage (ou vice versa) rendu sur le serveur et ensuite avoir une belle JS client (backbone/etc) exécuter le reste. Vous ne pouvez pas communiquer à 100% avec le RESTE de l'api via le JS client, mais vous permettra de faire un peu de travail, si nécessaire, pour rendre le sourir de l'expérience.

Je pense que c'est un de ces "ça dépend" sortes de problèmes et la réponse est "ça dépend" sur ce que vous faites, que vous servez et quel genre d'expérience que vous souhaitez recevoir. Étant donné que je pense que vous pouvez choisir entre 2 ou 3 ou un hybride.

Answer 5

Nous utilisons la variante suivante de #3: Faire un JSON-seulement le REPOS de l'API serveur. Faire un site web HTML serveur. HTML serveur web n'est pas, comme dans votre variante, un client pour le RESTE de l'API serveur. Au lieu de cela, les deux sont pairs. Pas loin en dessous de la surface, il y a une API qui fournit la fonctionnalité que les deux serveurs ont besoin.

Nous ne sommes pas au courant de tout 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.