ruby on rails 3 - tutorial - ¿Servidor y cliente de REST JSON API separados?

rails json api (18)

Estoy a punto de crear un montón de aplicaciones web desde cero. (Consulte http://50pop.com/code para obtener una descripción general). Me gustaría que se pueda acceder a ellos desde muchos clientes diferentes: sitios web front-end, aplicaciones para teléfonos inteligentes, servicios web de fondo, etc. Así que realmente quiero una API REST JSON para cada uno.

Además, prefiero trabajar en el back-end, por lo que soñé despierto con mi enfoque en la API y contratando a otra persona para crear la interfaz de usuario de front-end, ya sea un sitio web, iPhone, Android u otra aplicación.

Por favor, ayúdame a decidir qué enfoque debo tomar:

JUNTOS EN LOS RIELES
Haz una aplicación web Rails muy estándar. En el controlador, haga el conmutador respond_with para servir JSON o HTML. La respuesta JSON es entonces mi API.
Pro: Muchos precedentes. Grandes estándares y muchos ejemplos de cómo hacer las cosas de esta manera.
Contras: No necesariamente queremos que la API sea igual a la aplicación web. No me gusta si / luego responda con cambio de enfoque. Mezclando dos cosas muy diferentes (UI + API).

REST SERVER + JAVASCRIPT-HEAVY CLIENT
Cree un servidor de API REST solo para JSON. Use Backbone o Ember.js para JavaScript del lado del cliente para acceder directamente a la API, mostrando las plantillas en el navegador.
Pro: Me encanta la separación de API y cliente. La gente inteligente dice que este es el camino a seguir. Genial en teoría. Parece vanguardista y emocionante.
Con: No hay mucho precedente. No hay muchos ejemplos de esto bien hecho. Los ejemplos públicos (twitter.com) se sienten lentos e incluso se están alejando de este enfoque.

REST SERVER + SERVIDOR LADO HTML CLIENTE
Cree un servidor de API REST solo para JSON. Cree un cliente de sitio web HTML básico, que acceda solo a la API REST. Menos JavaScript del lado del cliente.
Pro: Me encanta la separación de API y cliente. Pero el servicio de HTML5 simple es bastante infalible y no requiere muchos clientes.
Con: No hay mucho precedente. No hay muchos ejemplos de esto bien hecho. Los marcos no soportan esto también. No estoy seguro de cómo abordarlo.

Especialmente buscando consejos de experiencia, no solo en teoría.

Actualmente estoy trabajando para convertir un enorme CMS de la opción 1 a la opción 3, y va bien. Elegimos representar el lado del servidor de marcado porque el SEO es un gran problema para nosotros, y queremos que los sitios tengan un buen desempeño en los teléfonos móviles.

Estoy usando node.js para el back-end del cliente y un puñado de módulos para ayudarme. Estoy algo adelantado en el proceso, pero la base está establecida y es una cuestión de revisar los datos para garantizar que todo funcione correctamente. Esto es lo que estoy usando:

Express para la fundación de la aplicación.
(https://github.com/visionmedia/express)
Solicitud para obtener los datos.
(https://github.com/mikeal/request)
Subraya las plantillas que se representan en el lado del servidor. Reutilizo estos en el cliente.
(https://github.com/documentcloud/underscore)
UTML envuelve las plantillas de subrayado para que funcionen con Express.
(https://github.com/mikefrey/utml)
Upfront recopila plantillas y le permite elegir las que se envían al cliente.
(https://github.com/mrDarcyMurphy/upfront)
Express Expose pasa los datos extraídos, algunos módulos y plantillas al front-end.
(https://github.com/visionmedia/express-expose)
Backbone crea modelos y vistas en el front-end después de tragar los datos que se transmitieron.
(https://github.com/documentcloud/backbone)

Ese es el núcleo de la pila. Algunos otros módulos que he encontrado útiles:

fleck (https // github.com / trek / fleck)
momento (https // github.com / timrwood / momento)
stylus (https // github.com / LearnBoost / stylus)
smoosh (https // github.com / fat / smoosh)
... aunque estoy buscando en gruñido (https // github.com / cowboy / grunt)
seguimiento de la consola (//github.com/LearnBoost/console-trace).

No, no estoy usando coffeescript.

Esta opción está funcionando muy bien para mí. Los modelos en el back-end son inexistentes porque los datos que obtenemos de la API están bien estructurados y los estoy pasando literalmente al front-end. La única excepción es nuestro modelo de diseño en el que agrego un atributo único que hace que la representación sea más inteligente y ligera. No utilicé ninguna biblioteca de modelos sofisticados para eso, solo una función que agrega lo que necesito en la inicialización y se devuelve a sí misma.

(perdón por los enlaces raros, soy demasiado n00b para el desbordamiento de pila para dejarme publicar tantos)

Algunas respuestas geniales aquí ya, definitivamente recomendaría # 2 o # 3, la separación es buena conceptualmente pero también en la práctica.

Puede ser difícil predecir cosas como la carga y los patrones de tráfico en una API y los clientes que atienden la API de forma independiente tienen un tiempo más fácil de aprovisionamiento y escalado. Si tiene que hacer eso con patrones de acceso web humanos, es menos fácil. Además, su uso de API podría terminar aumentando mucho más rápido que su cliente web y luego podrá ver dónde dirigir sus esfuerzos.

Entre el # 2 # 3 realmente depende de sus objetivos (estoy de acuerdo en que el # 2 es probablemente el futuro de las aplicaciones web), pero tal vez quiera algo más directo si ese canal solo va a ser uno de muchos.

Decidí apostar por la arquitectura de la Opción # 2 para Infiniformes , ya que me proporcionó una excelente manera de separar la UI de la lógica empresarial.

Una ventaja de esto es que los servidores API pueden escalar independientemente de los servidores web. Si tiene varios clientes, entonces los sitios web no tendrán que escalar en la misma medida que los servidores web, ya que algunos clientes se basarán en el teléfono / tableta o el escritorio.

Este enfoque también le proporciona una buena base para abrir su API a sus usuarios, especialmente si usa su propia API para proporcionar toda la funcionalidad para su sitio web.

El servidor REST + el cliente pesado de JavaScript fue el principio que seguí en mi trabajo reciente.

El servidor REST se implementó en node.js + Express + MongoDB (muy buen rendimiento de escritura) + Mongoose ODM (ideal para datos de modelado, validaciones incluidas) + CoffeeScript (ahora sería ES2015) que funcionó bien para mí. Node.js podría ser relativamente joven en comparación con otras posibles tecnologías del lado del servidor, pero me permitió escribir API sólidas con pagos integrados.

He utilizado Ember.js como marco de JavaScript y la mayor parte de la lógica de la aplicación se ejecutó en el navegador. He usado SASS (SCSS específicamente) para el preprocesamiento de CSS.

Ember es un marco maduro respaldado por una comunidad fuerte. Es un marco muy potente con mucho trabajo que se ha centrado recientemente en el rendimiento, como el nuevo motor de renderizado Glimmer (inspirado por React).

Ember Core Team está en proceso de desarrollar FastBoot , que le permite ejecutar su lógica Ember de JavaScript en el lado del servidor (específicamente en node.js) y enviar al usuario el HTML pre-renderizado de su aplicación (que normalmente se ejecutaría en el navegador). Es genial para SEO y la experiencia del usuario ya que no espera tanto tiempo para que se muestre la página.

Ember CLI es una gran herramienta que le ayuda a organizar su código y le fue bien escalar con cada vez más bases de código. Ember también tiene su propio ecosistema de complementos y puede elegir entre una variedad de complementos de Ember . Puedes agarrar fácilmente Bootstrap (en mi caso) o Foundation y agregarlo a tu aplicación.

Para no servir todo a través de Express, elegí usar nginx para servir imágenes y clientes pesados en JavaScript. Usar el proxy nginx fue útil en mi caso:

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: Me encanta la separación de API y cliente. La gente inteligente dice que este es el camino a seguir. Genial en teoría. Parece vanguardista y emocionante.

Puedo decir que también es genial en la práctica. Otra ventaja de separar la API REST es que puede reutilizarla más tarde para otras aplicaciones. En un mundo perfecto, debería poder usar la misma API REST no solo para la página web, sino también para las aplicaciones móviles si decide escribir una.

Con: No hay mucho precedente. No hay muchos ejemplos de esto bien hecho. Los ejemplos públicos (twitter.com) se sienten lentos e incluso se están alejando de este enfoque.

Las cosas se ven diferentes ahora. Hay muchos ejemplos de cómo hacer REST API + muchos clientes que lo consumen.

En Boundless , hemos profundizado con la opción # 2 y la hemos lanzado a miles de estudiantes. Nuestro servidor es una API REST JSON (Scala + MongoDB), y todo el código de nuestro cliente se entrega directamente desde CloudFront (es decir: www.boundless.com es solo un alias para CloudFront).

Pros:

De vanguardia / emocionante
Una gran cantidad de dinero por su dinero: API le da la base para su propio cliente web, clientes móviles, acceso de terceros, etc.
Transferencias de página / carga extremadamente rápidas

Contras:

No SEO amigable / listo sin mucho más trabajo.
Requiere gente de primera línea de la web que esté lista para hacer frente a la realidad de una experiencia de sitio que es 70% javascript y lo que eso significa.

Creo que este es el futuro de todas las aplicaciones web.

Algunas reflexiones para la gente de front-end web (que es donde toda la novedad / desafío tiene esta arquitectura):

CoffeeScript. Mucho más fácil de producir código de alta calidad.
Columna vertebral. Gran manera de organizar tu lógica, y comunidad activa.
HAMLC. Haml + CoffeeScript templates => JS.
HABLAR CON DESCARO A

Hemos creado un arnés para nuestro desarrollo de front-end llamado ''Spar'' (Rocketship de aplicación de página única) que es efectivamente el canal de activos de Rails optimizado para el desarrollo de aplicaciones de página única. Estaremos abiertos en las próximas semanas en nuestra página de github , junto con una publicación de blog que explica cómo usarla y la arquitectura en general con mayor detalle.

ACTUALIZAR:

Con respecto a las preocupaciones de la gente con Backbone, creo que están sobrevalorados. Backbone es mucho más un principio organizativo que un marco profundo. El sitio de Twitter en sí mismo es una bestia gigante de Javascript que cubre todos los rincones de millones de usuarios y navegadores antiguos, mientras carga tweets en tiempo real, recolecta basura, muestra gran cantidad de multimedia, etc. De todos los sitios js puros que he visto. Visto, Twitter es el extraño. Ha habido muchas aplicaciones increíblemente complicadas entregadas a través de JS que funcionan muy bien.

Y su elección de arquitectura depende totalmente de sus objetivos. Si está buscando la forma más rápida de brindar soporte a múltiples clientes y tiene acceso a un buen talento de front-end, invertir en una API independiente es una excelente manera de hacerlo.

He optado por un enfoque híbrido en el que utilizamos Sinatra como base, ActiveRecord / Postgress, etc. para ofrecer rutas de página (plantillas delgadas) para exponer una API REST que la aplicación web puede usar. En el desarrollo temprano, el hecho de rellenar las opciones de selección se realiza a través de la representación de los ayudantes en la plantilla delgada, pero a medida que nos acercamos a la producción, esto se intercambia por una llamada AJAX a una API REST a medida que comenzamos a preocuparnos más por las velocidades de carga de páginas, etc.

Las cosas que son fáciles de representar en Slim se manejan de esa manera, y las cosas (llenar formularios, recibir datos POST de formularios de jQuery. submitHandler la submitHandler , etc., es absolutamente AJAX)

Las pruebas son un problema. Ahora mismo estoy perplejo tratando de pasar datos JSON a una prueba POST de Rack :: Test .

La construcción de una API JSON en Rails es de primera clase. La gema JSONAPI :: Resources hace el trabajo pesado para una API especificada en http://jsonapi.org .

Llevo alrededor de 2 meses en un proyecto de 3 meses que toma el segundo enfoque que describimos aquí. Utilizamos un lado del servidor RESTful API con backbone.js en el frente. Handlebars.js administra las plantillas y jQuery maneja la manipulación de AJAX y DOM. Para los navegadores más antiguos y las arañas de búsqueda, hemos recurrido a la representación del lado del servidor, pero estamos usando las mismas plantillas HTML que la interfaz de Handlebars con Mozilla Rhino.

Elegimos este enfoque por muchas razones diferentes, pero estamos muy conscientes de que es un poco arriesgado dado que aún no se ha probado en gran escala. Todo lo mismo, todo va bastante bien hasta ahora.

Hasta ahora solo hemos estado trabajando con una API, pero en la siguiente fase del proyecto trabajaremos con una segunda API. El primero es para grandes cantidades de datos, y el segundo actúa más como un CMS a través de una API.

Tener estas dos partes del proyecto actuando de manera completamente independiente entre sí fue una consideración clave en la selección de esta infraestructura. Si está buscando una arquitectura para combinar diferentes recursos independientes sin ninguna dependencia, este es un enfoque que vale la pena ver.

Me temo que no soy un tipo Ruby, así que no puedo comentar sobre los otros enfoques. A veces está bien tomar un riesgo. Otras veces es mejor jugar seguro. Te harás depender del tipo de proyecto.

La mejor de las suertes con su elección aquí. Con ganas de ver lo que otros comparten también.

Me gusta el # 3 cuando mi sitio web no va a ser una implementación 100% CRUD de mis datos. Lo que aún está por suceder.

Prefiero Sinatra y solo dividiré la aplicación en algunas aplicaciones de rack diferentes con diferentes propósitos. Haré una aplicación de rack específica para la API que cubrirá lo que necesito para la API. Entonces quizás una aplicación de rack de usuario que presente mi página web. A veces esa versión consultará la API si es necesario, pero generalmente solo se relaciona con el sitio html.

No me preocupo por eso y simplemente hago una consulta de la capa de persistencia desde el lado del usuario si la necesito. No me preocupa demasiado crear una separación completa, ya que generalmente terminan cumpliendo diferentes propósitos.

Aquí hay un ejemplo muy simple de usar múltiples aplicaciones de rack. Agregué un ejemplo de jquery rápido allí para que lo veas golpear la aplicación API. Puede ver lo sencillo que puede ser con sinatra y montar varias aplicaciones de rack con diferentes propósitos.

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

Muy bien preguntado. +1. Por supuesto, esta es una referencia futura útil para mí. También @Aaron y otros agregaron valor a la discusión. Al igual que Ruby, esta pregunta es igualmente aplicable a otros entornos de programación.

He utilizado las dos primeras opciones. El primero para numerosas aplicaciones y el segundo para mi proyecto de código abierto Cowoop

Opción 1
Este es sin duda el más popular. Pero me parece que la implementación es mucho http-ish. El código inicial de cada API se ocupa del objeto de solicitud. Así que el código API es más que código puro ruby / python / otro lenguaje.

opcion 2
Siempre me ha gustado esto.
Esta opción también implica que HTML no se genera en tiempo de ejecución en el servidor. Así es como la opción 2 es diferente de la opción 3. Pero se crean como html estáticos utilizando un script de compilación. Cuando se cargan en el lado del cliente, estos HTML llamarían al servidor API como cliente JS API.
La separación de las preocupaciones es una gran ventaja. Y muy a su gusto (y el mío), los expertos de backend implementan las API de backend, las prueban fácilmente como el código de idioma habitual sin preocuparse por el código de solicitud http / framework.
Esto realmente no es tan difícil como suena en el lado frontal. Las llamadas a la API y los datos resultantes (en su mayoría json) están disponibles para su plantilla del lado del cliente o MVC.
Menos procesamiento del lado del servidor. Esto significa que puede optar por hardware de productos básicos / servidor menos costoso.
Más fácil de probar capas de forma independiente, más fácil de generar documentos API.
Tiene algunas desventajas.
Muchos desarrolladores encuentran que esto es demasiado complejo y difícil de entender. Así que lo más probable es que la arquitectura pueda ser criticada.
i18n / l10n es duro. Dado que el HTML se genera esencialmente el tiempo de compilación es estático, se necesitan múltiples compilaciones por lenguaje compatible (lo que no es necesariamente algo malo). Pero incluso con eso, es posible que tenga casos de esquina alrededor de l10n / i18n y tenga que tener cuidado.

Opcion 3
La codificación de back-end en este caso debe ser la misma que la segunda opción. La mayoría de los puntos para la opción 2 son aplicables aquí también.
Las páginas web se procesan en tiempo de ejecución utilizando plantillas del lado del servidor. Esto hace que i18n / l10n sea mucho más fácil con técnicas más establecidas / aceptadas. Puede ser una llamada http menos para un contexto esencial necesario para la representación de la página como usuario, idioma, moneda, etc. Por lo tanto, el procesamiento del lado del servidor se incrementa con la representación, pero posiblemente se compensa con menos llamadas http al servidor API.
Ahora que las páginas se procesan en el servidor, el frontend ahora está más vinculado con el entorno de programación. Esto podría no ser siquiera una consideración para muchas aplicaciones.

Caso de Twitter

Según tengo entendido, Twitter podría realizar su representación de página inicial en el servidor, pero para las actualizaciones de la página aún tiene algunas llamadas a la API y plantillas del lado del cliente para manipular el DOM. Entonces, en tal caso, tiene plantillas dobles que mantener, lo que agrega cierta sobrecarga y complejidad. No todos pueden permitirse esta opción, a diferencia de Twitter.

Nuestro proyecto Stack

Resulta que uso Python. Yo uso JsonRPC 2.0 en lugar de REST. Sugiero REST, aunque me gusta la idea de JsonRPC por varias razones. Yo uso las siguientes bibliotecas. Alguien que esté considerando la opción 2/3 podría encontrarlo útil.

Servidor API: Python Un micro marco web rápido - Flask
Servidor frontend: Nginx
Lado del cliente MVC: Knockout.js
Otras herramientas relevantes / libs:
- Jquery
- Accounting.js para moneda de dinero
- Webshim : Webshim navegador
- director : enrutamiento del lado del cliente
- sphc : generación de HTML

Mi conclusión y recomendación

Opción 3 !.

Dicho todo, he usado la opción 2 con éxito, pero ahora me inclino por la opción 3 para mayor simplicidad. Generar páginas HTML estáticas con script de compilación y servirlas con uno de los servidores ultra rápidos que se especializan en servir páginas estáticas es muy tentador (Opción 2).

Normalmente voy por la segunda opción, usando Rails para construir la API y la red troncal para las cosas de JS. Incluso puede obtener un panel de administración de forma gratuita con ActiveAdmin . He enviado decenas de aplicaciones móviles con este tipo de backend. Sin embargo, depende en gran medida si su aplicación es interactiva o no.

Hice una presentación sobre este enfoque en el último RubyDay.it : http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

Para la tercera opción, con el fin de obtener la capacidad de respuesta de la segunda, es posible que desee probar pajax como Github lo hace.

Optamos por el # 2 al construir gaug.es. Trabajé en la API (ruby, sinatra, etc.) y mi socio comercial, Steve Smith, trabajó en el front-end (cliente javascript).

Pros:

Muévete rápido en paralelo. Si trabajara por delante de Steve, podría seguir creando API para nuevas características. Si trabajaba delante de mí, podría falsificar la API muy fácilmente y construir la interfaz de usuario.
API de forma gratuita. Tener acceso abierto a los datos en su aplicación se está convirtiendo rápidamente en una característica estándar. Si comienzas con una API desde cero, obtendrás esto gratis.
Separación limpia. Es mejor pensar en tu aplicación como una API con los clientes. Claro, el primer y más importante cliente puede ser uno web, pero te permite crear fácilmente otros clientes (iPhone, Android).

Contras:

Compatibilidad al revés. Esto está más relacionado con una API que con su pregunta directa, pero una vez que su API está disponible, no puede simplemente romperla o romper dos a todos sus clientes. Esto no significa que tenga que moverse más lento, pero sí significa que a menudo tiene que hacer que dos cosas funcionen a la vez. Agregar a la API o nuevos campos está bien, pero cambiar / eliminar no se debe hacer sin la creación de versiones.

No puedo pensar en más contras en este momento.

Conclusión: API + JS client es el camino a seguir si planea lanzar una API.

PS También recomendaría documentar completamente su API antes de lanzarla. El proceso de documentar la API de Gaug.es realmente nos ayudó a mejorar.

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

Para atyourservice.com.cy, estamos utilizando plantillas renderizadas del lado del servidor para páginas especialmente para cubrir la parte de se. Y usando la API para interacciones después de la carga de la página. Como nuestro marco es MVC, todas las funciones del controlador se duplican en la salida json y en la salida html. Las plantillas están limpias y reciben solo un objeto. Esto se puede transformar en plantillas js en segundos. Siempre mantenemos las plantillas del lado del servidor y simplemente volvemos a convertir a js a petición.

Personalmente prefiero la opción (3) como solución. Se usa en casi todos los sitios que tiene un antiguo empleador (nombre del hogar). Esto significa que puede obtener algunos desarrolladores de aplicaciones para usuario que saben todo sobre Javascript, las peculiaridades del navegador y otras cosas para codificar su interfaz. Solo necesitan saber "curl xyz y obtendrás un poco de json" y listo.

Mientras tanto, sus empleados pesados de back-end pueden codificar a los proveedores de Json. Estos individuos no necesitan pensar en la presentación en absoluto, y en lugar de eso, deben preocuparse por los backends inestables, los tiempos de espera, el manejo elegante de errores, los grupos de conexión de bases de datos, los subprocesos y la escala, etc.

La opción 3 le ofrece una buena arquitectura sólida de tres niveles. Significa que las cosas que escupes al frente son SEO amigable, se pueden hacer que funcionen con navegadores antiguos o nuevos (y aquellos con JS desactivado), y podrían ser plantillas de Javascript del cliente si así lo deseas haga cosas como manejar los navegadores antiguos / googlebot con HTML estático, pero envíe experiencias dinámicas desarrolladas por JS a las personas que utilizan el navegador Chrome más reciente o lo que sea.

En todos los casos que he visto en la Opción 3, ha sido una implementación personalizada de algunos PHP que no son especialmente transferibles entre proyectos, y mucho menos a la tierra de código abierto. Supongo que más recientemente PHP puede haber sido reemplazado con Ruby / Rails, pero el mismo tipo de cosas sigue siendo cierto.

FWIW, $ current_employer podría hacer con la opción 3 en un par de lugares importantes. Estoy buscando un buen marco de Ruby para construir algo. Estoy seguro de que puedo juntar una carga de gemas, pero preferiría un solo producto que en general proporcione una solución de almacenamiento en caché conectado, "curling", opcional, opcional con memcache / nosql. Ahí estoy fallando en encontrar algo coherente :-(

Prefiero ir por la ruta # 2 y # 3. Principalmente porque el # 1 viola la separación de preocupaciones y mezcla todo tipo de cosas. Eventualmente encontrará la necesidad de tener un punto final de API que no tenga una página HTML / etc coincidente y estará en un arroyo con puntos finales JSON y HTML entremezclados en la misma base de código. Se convierte en un desastre, incluso si es su MVP, tendrá que volver a escribirlo eventualmente porque es tan desordenado que ni siquiera vale la pena rescatarlo.

Ir con # 2 o # 3 le permite tener completamente una API que actúa igual (en su mayor parte) independientemente. Esto proporciona una gran flexibilidad. No estoy 100% vendido en Backbone / ember / whatever / etc.js todavía. Creo que es genial, pero como estamos viendo con Twitter, esto no es óptimo. PERO ... Twitter también es una gran bestia de una empresa y tiene cientos de millones de usuarios. Por lo tanto, cualquier mejora puede tener un gran impacto en el resultado final en varias áreas de varias unidades de negocios. Creo que hay más en la decisión que solo la velocidad y no nos están permitiendo eso. Pero esa es solo mi opinión. Sin embargo, no descontamos el backbone y sus competidores. Estas aplicaciones son excelentes para usar, son muy limpias y responden muy bien (en su mayor parte).

La tercera opción también tiene algún encanto válido. Aquí es donde seguiría el principio de Pareto (regla 80/20) y tendría el 20% de su marca principal (o viceversa) representada en el servidor y luego tendría un buen cliente JS (backbone / etc) ejecutando el resto . Es posible que no se esté comunicando al 100% con la API REST a través del cliente JS, pero hará algunos trabajos si es necesario para mejorar la experiencia del usuario.

Creo que este es uno de esos tipos de problemas "depende" y la respuesta es "depende" de lo que estás haciendo, a quién estás atendiendo y qué tipo de experiencia quieres que reciban. Dado que creo que puedes decidir entre 2 o 3 o un híbrido de ellos.

Representación isomórfica y mejora progresiva. Que es a lo que creo que te dirigías en la opción tres.

la representación isomórfica significa usar la misma plantilla para generar el lado del servidor de marcado que usa en el código del lado del cliente. Elija un lenguaje de plantillas con buenas implementaciones del lado del servidor y del lado del cliente. Cree html completamente horneados para sus usuarios y envíelos por el cable. Usa el almacenamiento en caché también.

una mejora progresiva significa comenzar a ejecutar y renderizar en el lado del cliente y escuchar los eventos una vez que tenga todos los recursos descargados y pueda determinar las capacidades de un cliente. Recurriendo a la funcionalidad funcional sin script del cliente siempre que sea posible para la accesibilidad y la compatibilidad con versiones anteriores.

Sí, por supuesto, escriba una json api independiente para esta funcionalidad de la aplicación. Pero no vaya tan lejos como para escribir una api de json para cosas que funcionan bien como documentos html estáticos.

Una pregunta muy agradable y me sorprende porque pensé que esta es una tarea muy común hoy en día, ya que tendré muchos recursos para este problema, pero no fue cierto.

Mis pensamientos son los siguientes: - Cree un módulo que tenga la lógica común entre los controladores API y los controladores HTML sin devolver json o renderizando html, e incluya este módulo tanto en el controlador HTML como en el controlador API, luego haga lo que desee, por ejemplo :

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

Usamos la siguiente variante de # 3: Crear un servidor de API REST solo para JSON. Hacer un servidor de sitio web HTML. El servidor web HTML no es, como en su variante, un cliente para el servidor API REST. En cambio, los dos son compañeros. No muy lejos de la superficie, hay una API interna que proporciona la funcionalidad que necesitan los dos servidores.

No tenemos conocimiento de ningún precedente, así que es algo experimental. Hasta ahora (a punto de entrar en beta), ha funcionado bastante bien.