¿Separar el servidor y el cliente de la API REST JSON? [cerrado]

Estoy a punto de crear un montón de aplicaciones web desde cero. (Véase http://50pop.com/code para una visió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 back-end, etc. Así que realmente quiero una API REST JSON para cada uno.

Además, prefiero trabajar en el back-end, así que sueño despierto manteniendo mi enfoque puramente en la API y contratando a alguien más para hacer la interfaz de usuario del front-end, ya sea un sitio web, iPhone, Android o otra aplicación.

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

JUNTOS EN RIELES

Hacer una aplicación web Rails muy estándar. En el controlador, haga el interruptor respond_with, para servir ya sea JSON o HTML. La respuesta JSON es entonces mi API.

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

Contra: No necesariamente quiero que la API sea la misma que la aplicación web. No me gusta si / entonces respond_with interruptor de enfoque. Mezcla de dos cosas muy diferentes (UI + API).

SERVIDOR REST + CLIENTE JAVASCRIPT-PESADO

Cree un servidor API REST solo para JSON. Usa Backbone o Brasa.js para JavaScript del lado del cliente para acceder a la API directamente, mostrando 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 de vanguardia y emocionante.

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

SERVIDOR REST + CLIENTE HTML DEL LADO DEL SERVIDOR

Cree un servidor API REST solo para JSON. 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 es intensivo para el cliente.

Contra: No hay mucho precedente. No hay muchos ejemplos de esto bien hecho. Los frameworks no soportan esto también. No estoy seguro de cómo abordarlo.

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