¿Servidor y cliente REST JSON API separados?

Estoy a punto de crear un conjunto 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 diferentes clientes: sitios web front-end, aplicaciones para teléfonos inteligentes, servicios web de backend, etc. Así que realmente quiero un API JSON REST para cada uno.

Además, prefiero trabajar en el back-end, así que sueño pensando en mantener mi enfoque exclusivamente en la API, y contratar a alguien más para crear la interfaz de usuario frontal, ya sea un sitio web, iPhone, Android u otra aplicación.

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

JUNTOS EN CARRILES

Cree una aplicación web de Rails muy estándar. En el controlador, haz el interruptor de respuesta_con, para servir JSON o HTML. La respuesta JSON es entonces mi API.

Pro: muchos precedentes. Excelentes estándares y muchos ejemplos de hacer las cosas de esta manera.

Con: No necesariamente quiere que la API sea igual que la aplicación web. No me gusta si / luego respondo con el enfoque de cambio. Mezclando dos cosas muy diferentes (UI + API).

REST SERVER + JAVASCRIPT-HEAVY CLIENT

Cree un servidor REST API JSON-only. Utilice Backbone o Ember.js para que JavaScript del lado del cliente acceda a la API directamente, mostrando las plantillas en el navegador.

Pro: me encanta la separación de API y cliente. Las personas inteligentes dicen que este es el camino a seguir. Genial en teoría. Parece de vanguardia 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 alejan de este enfoque.

REST SERVER + SERVER-SIDE HTML CLIENT

Cree un servidor REST API JSON-only. Cree un cliente de sitio web HTML básico, que solo acceda a la API REST. Menos JavaScript del lado del cliente.

Pro: me encanta la separación de API y cliente. Pero servir HTML5 simple es bastante infalible y no exige mucho al cliente.

Con: No hay mucho precedente. No hay muchos ejemplos de esto bien hecho. Los marcos no son compatibles con esto también. No estoy seguro de cómo abordarlo.

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

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

    Pros:

    • De vanguardia / emocionante
    • Gran cantidad de dinero: API te proporciona la base para tu propio cliente web, clientes móviles, acceso de terceros, etc.
    • extremadamente rápido carga de sitio / transiciones de página

    Contras:

    • No es compatible con SEO / listo sin mucho trabajo.
    • Requiere gente de primera línea de front-end web que está lista para hacer frente con la realidad de una experiencia de sitio que es 70% de javascript y lo que eso significa.

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

    Algunos pensamientos para la gente del front-end web (que es donde todo el new-ness / challenge se le da a esta architecture):

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

    Hemos creado un arnés para nuestro desarrollo de front-end llamado ‘Spar’ (Single Page App Rocketship) que es efectivamente el conducto de activos de Rails adaptado para el desarrollo de una sola página de aplicaciones. En las próximas semanas, seremos proveedores abiertos en nuestra página github , junto con una publicación en el blog que explicará cómo usarla y la architecture general en mayor detalle.

    ACTUALIZAR:

    Con respecto a las preocupaciones de las personas con Backbone, creo que están sobrevaloradas. El backbone es mucho más un principio de organización que un marco profundo. El sitio de Twitter en sí es una bestia gigante de Javascript que cubre cada esquina de millones de usuarios y navegadores heredados, al cargar tweets en tiempo real, recolectar basura, mostrar gran cantidad de contenido multimedia, etc. De todos los sitios ‘puros’ de js que tengo visto, Twitter es el extraño. Ha habido muchas aplicaciones impresionantemente complicadas entregadas a través de JS que van muy bien.

    Y su elección de architecture depende completamente de sus objectives. Si está buscando la forma más rápida de dar soporte a múltiples clientes y tener acceso a un buen talento de front-end, invertir en una API independiente es una gran manera de hacerlo.

    Muy bien preguntado +1. Por supuesto, esta es una referencia útil futura 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 progtwigción.

    He usado las primeras dos opciones. El primero para numerosas aplicaciones y el segundo para mi proyecto de fuente abierta Cowoop

    Opción 1

    Este es sin duda el más popular. Pero encuentro que la implementación es mucho http-ish. El código inicial de cada API va al tratar con el objeto de solicitud. Así que el código API es más que puro Ruby / python / otro código de idioma.

    opcion 2

    Siempre me encantó 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 están comstackdas como html estático usando un script de comstackción. Cuando se cargan en el lado del cliente, estos HTML llamarían a API server como el cliente API de JS.

    • La separación de preocupaciones es una gran ventaja. Y para su gusto (y el mío), los expertos en back-end implementan API de backend, las prueban fácilmente como el código de lenguaje habitual sin preocuparse por el código de solicitud marco / http.

    • Esto realmente no es tan difícil como suena en el lado frontend. Las llamadas API y los datos resultantes (principalmente json) están disponibles para su plantilla del lado del cliente o MVC.

    • Menos procesamiento del lado del servidor. Significa que puede elegir hardware básico / 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 esto sobre ingeniería y difícil de entender. Entonces, es probable que la architecture sea criticada.

    • i18n / l10n es difícil. Dado que HTML se genera esencialmente, el tiempo de comstackción es estático, se necesitan comstackciones múltiples por idioma soportado (lo cual no es necesariamente algo malo). Pero incluso con eso, puede tener casos de esquina alrededor de l10n / i18n y debe tener cuidado.

    Opción 3

    La encoding de back-end en este caso debe ser igual 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 páginas como usuario, idioma, moneda, etc. Así, el procesamiento del lado del servidor se incrementa con el procesamiento, 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 progtwigción. Esto podría no ser siquiera una consideración para muchas aplicaciones.

    Caso de Twitter

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

    Nuestro proyecto Stack

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

    • Servidor API: Python Un micro framework de web rápido – Flask
    • Servidor frontend: Nginx
    • Cliente lado MVC: Knockout.js
    • Otras herramientas / libs relevantes:
      • Jquery
      • Accounting.js para dinero moneda
      • Webshim : polyfill de navegador cruzado
      • director : Enrutamiento del lado del cliente
      • sphc : generación HTML

    Mi conclusión y recomendación

    Opción 3 !.

    Dicho todo esto, he utilizado la opción 2 con éxito, pero ahora me inclino por la opción 3 por algo de simplicidad. Generar páginas HTML estáticas con script de comstackció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).

    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 de JavaScript).

    Pros:

    1. Muévete rápido en paralelo. Si trabajé antes que Steve, podría seguir creando API para nuevas funciones. Si él trabajó antes que yo, podría falsificar el API muy fácilmente y construir la interfaz de usuario.

    2. API gratis 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, obtienes esto gratis.

    3. Separación limpia Es mejor pensar en tu aplicación como una API con clientes. Claro, el primer y más importante cliente puede ser uno web, pero te prepara para crear fácilmente otros clientes (iPhone, Android).

    Contras:

    1. 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 puede dividir a todos sus clientes dos. Esto no significa que tengas que moverte más despacio, pero sí significa que a menudo debes 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 versionar.

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

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

    PD. También recomendaría documentar completamente su API antes de lanzarla. El proceso de documentación de API de Gaug.es realmente nos ayudó a imp

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

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

    Ir con el n. ° 2 o n. ° 3 te permite tener una API que actúe igual (en su mayor parte) independientemente. Esto proporciona una gran flexibilidad. Todavía no estoy 100% vendido en Backbone / Ember / whatever / etc.js. 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. Entonces, cualquier mejora puede tener un gran impacto en los resultados de varias áreas de varias unidades de negocio. Creo que hay más en la decisión que la velocidad solo y no nos dejan entrar en eso. Pero esa es solo mi opinión. Sin embargo, no descontaré la red troncal y sus competidores. Estas aplicaciones son geniales para usar y están muy limpias y son muy receptivas (en su mayor parte).

    La tercera opción también tiene un atractivo válido. Aquí es donde seguiría el principio de Pareto (regla 80/20) y obtendría el 20% de su marcado principal (o viceversa) en el servidor y luego tendría un buen cliente JS (backbone / etc) ejecutaría el rest del mismo . Es posible que no se comunique al 100% con la API REST a través del cliente JS, pero hará algún trabajo 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á haciendo, a quién sirve y qué tipo de experiencia quiere que reciba. Dado que creo que puedes decidir entre 2 o 3 o un híbrido de ellos.

    Actualmente estoy trabajando en la conversión de un enorme CMS de la opción 1 a la opción 3, y va bien. Elegimos presentar el lado del servidor de marcado porque SEO es un gran negocio para nosotros, y queremos que los sitios funcionen bien 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 un poco adelantado en el proceso, pero la base está establecida y es cuestión de revisar los datos para garantizar que todo funcione correctamente. Esto es lo que estoy usando:

    Ese es el núcleo de la stack. 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 gruñir (https // github.com / cowboy / gruñido)
    • rastro de la consola (//github.com/LearnBoost/console-trace).

    No, no estoy usando coffeescript.

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

    (lo siento por los enlaces extraños, soy demasiado n00b para el desbordamiento de stack que me permite publicar tantos)

    Usamos la siguiente variante de # 3: crear un servidor REST API solo para JSON. Haga un servidor de sitio web HTML. El servidor web HTML no es, como en su variante, un cliente del 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 conocemos ningún precedente, por lo que es algo experimental. Hasta ahora (a punto de ingresar a beta), ha funcionado bastante bien.

    Normalmente voy por la segunda opción, usando Rails para construir la API y la columna vertebral 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 back-end. 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, para obtener capacidad de respuesta de la segunda, es posible que desee probar pajax como lo hace Github.

    Tengo alrededor de 2 meses en un proyecto de 3 meses que requiere el segundo enfoque que ha descrito aquí. Usamos un lado del servidor API RESTful con backbone.js en el frente. Handlebars.js administra las plantillas y jQuery maneja la manipulación AJAX y DOM. Para navegadores antiguos y arañas de búsqueda, hemos recurrido a la representación del lado del servidor, pero estamos utilizando las mismas plantillas HTML que la interfaz de Handlebars con Mozilla Rhino.

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

    Hasta ahora solo hemos estado trabajando con una API, pero en la próxima 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 piezas del proyecto actuando de manera completamente independiente entre sí fue una consideración clave al seleccionar esta infraestructura. Si está buscando una architecture para combinar diferentes recursos independientes sin dependencias, entonces este es el enfoque que vale la pena ver.

    Me temo que no soy un Ruby, así que no puedo comentar sobre los otros enfoques. Algunas veces está bien arriesgarse. Otras veces es mejor ir a lo seguro. Te vas a ayudar según el tipo de proyecto.

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

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

    Prefiero Sinatra y simplemente dividiré la aplicación en diferentes aplicaciones de rack con diferentes propósitos. Haré una aplicación de rack específica de API que cubrirá lo que necesito para la API. Entonces tal vez una aplicación de rack de usuario que presentará mi página web. Algunas veces esa versión consultará la API si es necesario, pero generalmente solo se ocupa del sitio html.

    No me preocupo por eso y solo hago una consulta de capa de persistencia desde el lado del usuario si la necesito. No estoy demasiado preocupado con la creación de una separación completa, ya que por lo general terminan sirviendo a diferentes propósitos.

    Este es un ejemplo muy simple de uso de múltiples aplicaciones de rack. Agregué un ejemplo rápido de jquery para que lo veas golpear la aplicación API. Puedes ver lo simple que puede ser con sinatra y montar múltiples aplicaciones de rack con diferentes propósitos.

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

    Algunas buenas respuestas aquí, definitivamente recomendaría el n. ° 2 o n. ° 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 vemos que sirven la API de forma independiente tienen un tiempo más fácil de aprovisionamiento y escalado. Si tiene que hacer eso engarzado con patrones de acceso web humano, es menos fácil. Además, el uso de su API puede terminar escalando mucho más rápido que su cliente web y luego puede ver a dónde dirigir sus esfuerzos.

    Entre # 2 # 3 realmente depende de tus objectives – Estoy de acuerdo en que # 2 es probablemente el futuro de las webapps – ¡pero tal vez quieras algo más sencillo si ese canal solo va a ser uno de tantos!

    Para atyourservice.com.cy estamos utilizando plantillas renderizadas del lado del servidor para páginas especialmente para cubrir la parte se. Y usando la API para las interacciones después de la carga de la página. Como nuestro framework es MVC, todas las funciones del controlador se duplican en salida json y 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 js a pedido.

    Representación isomórfica y mejora progresiva. Para lo que creo que estabas yendo en la tercera opción.

    La representación isomórfica significa usar la misma plantilla para generar el marcado en el lado del servidor como se 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. Crea html completamente horneado para tus usuarios y envíalo por cable. Usa el almacenamiento en caché también.

    Los medios de mejora progresiva comienzan a realizar la ejecución y representación del lado del cliente y la escucha del evento una vez que se han descargado todos los recursos y se pueden determinar las capacidades del cliente. Volviendo a la funcionalidad funcional sin script de cliente siempre que sea posible para la accesibilidad y la compatibilidad con versiones anteriores.

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

    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 (excelente para modelar datos, validaciones incluidas) + CoffeeScript (ahora iría 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 una API sólida con pagos integrados.

    He usado Ember.js como marco de JavaScript y la mayoría 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 poderoso con mucho trabajo recientemente enfocado en el rendimiento, como el nuevo motor de renderizado Glimmer (inspirado en React).

    Ember Core Team está en proceso de desarrollar FastBoot , que le permite ejecutar su lógica de Ember de JavaScript en el lado del servidor (node.js específicamente) y enviar al usuario el HTML preprocesado de su aplicación (que normalmente se ejecutará en el navegador). Es ideal 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 una base de código creciente. Ember también tiene su propio ecosistema de complementos y puedes elegir entre variedad de Ember Addons . Puedes agarrar fácilmente Bootstrap (en mi caso) o Foundation y agregarlo a tu aplicación.

    Para no publicar todo a través de Express, elegí usar nginx para publicar imágenes y un cliente pesado 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. Las personas inteligentes dicen que este es el camino a seguir. Genial en teoría. Parece de vanguardia y emocionante.

    Puedo decir que también es genial en la práctica. Otra ventaja de separar REST API es que puedes reutilizarlo más tarde para otras aplicaciones. En un mundo perfecto, debería poder utilizar la misma API REST no solo para páginas web, sino también para 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 alejan de este enfoque.

    Las cosas se ven diferentes ahora. Hay muchos ejemplos de API REST + muchos clientes que la consumen.

    Decidí optar por la architecture de la Opción n.º 2 para Infiniforms , ya que proporcionaba una excelente manera de separar la interfaz de usuario de la lógica comercial.

    Una ventaja de esto es que los servidores API pueden escalar independientemente de los servidores web. Si tiene varios clientes, los sitios web no tendrán que escalarse en la misma medida que los servidores web, ya que algunos clientes pueden ser teléfonos / tabletas o equipos de escritorio.

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

    Una muy buena pregunta y estoy sorprendido ya que pensé que esta es una tarea muy común hoy en día, así que tendré muchos recursos para este problema, aunque resulte no ser cierto.

    Mis pensamientos son los siguientes: – Crear algún módulo que tenga la lógica común entre los controladores API y los controladores HTML sin devolver json o renderizar html, e incluir 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 

    He optado por un enfoque híbrido en el que usamos Sinatra como base, ActiveRecord / Postgress, etc. para que sirva las rutas de las páginas (plantillas delgadas) expongan una API REST que la aplicación web puede usar. En el desarrollo inicial, las opciones selectas se realizan a través de ayudantes que se convierten en plantillas delgadas, pero a medida que nos aproximamos a la producción se intercambian para una llamada AJAX a una API REST cuando comenzamos a preocuparnos más por las velocidades de carga de página, etc.

    Las cosas que es fácil de renderizar en Slim se manejan de esa manera, y cosas (rellenar formularios, recibir datos POST de formularios de submitHandler de submitHandler , etc, son todos AJAX)

    Las pruebas son un problema. En este momento estoy perplejo al intentar pasar datos JSON a una prueba POST Rack :: Test .

    Personalmente prefiero la opción (3) como solución. Se usa en casi todos los sitios que tiene un antiguo empleador (conocido). Significa que puede obtener algunos desarrolladores front-end que saben todo sobre Javascript, peculiaridades del navegador y otras cosas para codificar su interfaz. Solo necesitan saber “curl xyz y obtendrás algo de json” y se van.

    Mientras tanto, tus chicos pesados ​​de back-end pueden codificar a los proveedores de Json. Estos tipos no necesitan pensar en la presentación en absoluto, y en su lugar se preocupan por backends escamosos, tiempos de espera, manejo elegante de errores, grupos de conexiones de bases de datos, subprocesos, escalamiento, etc.

    La opción 3 le brinda una buena y sólida architecture de tres niveles. Significa que las cosas que escupió de la interfaz son SEO amigables, pueden funcionar con navegadores antiguos o nuevos (y aquellos con JS desactivado), y aún podrían ser plantillas de cliente de JavaScript si lo desean (para que puedan hacer cosas como manejar navegadores antiguos / googlebot con HTML estático, pero enviar experiencias dinámicas creadas por JS a personas que usan el último navegador Chrome o lo que sea).

    En todos los casos que he visto Opción 3, ha sido una implementación personalizada de algunos PHP que no es especialmente transferible entre proyectos, y mucho menos en territorio de Código abierto. Creo que más recientemente PHP pudo haber sido reemplazado por 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 Ruby para construir algo. Estoy seguro de que puedo unir una gran cantidad de gems, pero preferiría un solo producto que ofrezca, en general, una solución de caché de plantillas, ‘curling’, opcional de autenticación, memcache opcional / nosql conectada. Ahí estoy fracasando en encontrar algo coherente 🙁

    Crear una API JSON en Rails es de primera clase, la joya JSONAPI :: Resources hace el trabajo pesado para una API http://jsonapi.org especificada.