Отдельный сервер API REST JSON и клиент? [закрытый]

Я собираюсь создать кучу веб-приложений с нуля. (См. http://50pop.com/code обзор.) Я хотел бы, чтобы к ним можно было получить доступ из разных клиентов: интерфейсных веб-сайтов, приложений для смартфонов, бэкэнд-веб-сервисов и т. д. Поэтому я действительно хочу API REST JSON для каждого из них.

кроме того, я предпочитаю работать на задней панели, поэтому я мечтаю о том, чтобы я сосредоточился исключительно на API и нанял кого-то другого, чтобы сделать интерфейсный интерфейс, будь то веб-сайт, iPhone, Android, или другое приложение.

пожалуйста, помогите мне решить, какой подход я должен предпринять:

ВМЕСТЕ В РЕЛЬСЫ

сделайте очень стандартное веб-приложение Rails. В контроллере выполните переключатель respond_with, чтобы обслуживать JSON или HTML. Ответ JSON-это мой API.

Pro: большой прецедент. Большие стандарты & много примеров делать вещи таким образом.

Con: не обязательно хотите, чтобы API был таким же, как веб-приложение. Не нравится if/then respond_with switch подход. Смешивание двух очень разных вещей (UI + API).

REST SERVER + JAVASCRIPT-ТЯЖЕЛЫЙ КЛИЕНТ

создайте сервер REST API только для JSON. Используйте костяк или уголь.js для клиентского JavaScript для прямого доступа к API, отображения шаблонов в браузере.

Pro: мне нравится разделение API и клиента. Умные люди говорят, что это путь ходить. Отлично в теории. Кажется ультрасовременным и захватывающим.

Con: не так много прецедентов. Не так много примеров этого сделано хорошо. Публичные примеры (twitter.com) чувствовать себя вялым и даже переключаться от этого подхода.

REST SERVER + СЕРВЕРНЫЙ HTML-КЛИЕНТ

создайте сервер REST API только для JSON. Создайте базовый клиент веб-сайта HTML, который обращается только к API REST. Меньше JavaScript на стороне клиента.

Pro: мне нравится разделение API и клиента. Но обслуживание простого HTML5 является довольно надежным и не интенсивным для клиентов.

Con: не так много прецедентов. Не так много примеров этого сделано хорошо. Фреймворки не поддерживают это. Не знаю, как к этому подойти.

специально искала советы из опыта, а не только в теории.

18 ответов


At безграничная, мы углубились в Вариант №2 и развернули его для тысяч студентов. Наш сервер-JSON REST API (Scala + MongoDB), и весь наш клиентский код обслуживается прямо из CloudFront (т. е.: www.boundless.com это просто псевдоним для CloudFront).

плюсы:

  • передовая/интересное
  • много взрыва для вашего доллара: API дает вам основу для вашего собственного веб-клиента, мобильных клиентов, стороннего доступа, так далее.
  • чрезвычайно быстрая загрузка сайта / переходов страницы

плюсы:

  • Не SEO дружественный / готовый без намного больше работы.
  • требует первоклассных веб-интерфейсных людей, которые готовы справиться с реальностью сайта, который на 70% javascript и что это значит.

Я думаю, что это будущее всего веб-приложения.

некоторые мысли для веб-интерфейсных людей (где вся новизна / вызов дана этой архитектуре):

  • CoffeeScript. Гораздо проще производить качественный код.
  • костяк. Отличный способ организовать свою логику и активное сообщество.
  • HAMLC. Haml + CoffeeScript templates => JS.
  • Сасс

мы построили жгут проводов для нашей интерфейсной разработки под названием " Spar "(Single Page App Rocketship), который является эффективным конвейером активов из рельсов, настроенных для одной страницы разработка приложений. Мы будем открыты для поиска в течение следующих нескольких недель на нашем github страница, а также сообщение в блоге, объясняющее, как использовать его и общую архитектуру более подробно.

обновление:

Что касается проблем людей с позвоночником, я думаю, что они переоценены. Костяк - это скорее организационный принцип, чем глубокая основа. Сам сайт Twitter-это гигантский зверь Javascript, охватывающий каждый угловой случай в миллионах пользователи и устаревшие браузеры, при загрузке твитов в режиме реального времени, сбор мусора, отображение большого количества мультимедиа и т. д. Из всех "чистых" сайтов js, которые я видел, Twitter является странным. Было много впечатляюще сложных приложений, доставленных через JS, которые очень хорошо.

и ваш выбор архитектуры полностью зависит от ваших целей. Если вы ищете самый быстрый способ поддержки нескольких клиентов и имеете доступ к хорошему интерфейсному таланту, инвестирование в автономный API-отличный способ ходить.


очень хорошо попросил. +1. Конечно, это будущая полезная ссылка для меня. Также @Aaron и другие добавили ценность обсуждению. Как и Ruby, этот вопрос одинаково применим к другим средам программирования.

Я использовал первые два варианта. Первый для многочисленных приложений и второй для моего проекта с открытым исходным кодом Cowoop

1

этот, без сомнения, самый популярный. Но я считаю, что реализация очень много http-ish. Каждый исходный код API имеет дело с объектом запроса. Таким образом, код API-это больше, чем чистый код ruby/python/другого языка.

2

Мне всегда это нравилось.

этот параметр также означает, что HTML не является средой выполнения, генерируемой на сервере. Это как вариант 2 отличается от варианта 3. Но строятся как статический html, используя скрипт сборки. При загрузке на стороне клиента этот HTML вызовет сервер API как JS API клиент.

  • разделение является большим преимуществом. И очень по своему вкусу (и моему) бэкэнд-эксперты реализуют бэкэнд-API, тестируют их легко, как обычный языковой код, не беспокоясь о коде запроса framework/ http.

  • Это действительно не так сложно, как кажется на frontend стороны. Вызовы API и результирующие данные (в основном json) доступны для вашего шаблона на стороне клиента или MVC.

  • меньше обработки на стороне сервера. Это означает, что вы можете пойти на товарное оборудование/ менее дорогой сервер.

  • легче тестировать слои независимо, проще создавать документы API.

У него есть некоторые недостатки.

  • многие разработчики считают, что это над инженерии и трудно понять. Поэтому есть вероятность, что архитектуру могут критиковать.

  • реализация i18n/команде l10n сложно. Поскольку HTML по существу генерируется, время сборки статично, требуется несколько сборок на Поддерживаемый язык (что не обязательно плохо). Но даже с этим вы можете иметь угловые случаи вокруг l10n / i18n и должны быть осторожны.

3

Backend кодирование в этом случае должно быть таким же, как второй вариант. Большинство пунктов для варианта 2 применимы и здесь.

веб-страницы отображаются во время выполнения, используя шаблоны на стороне сервера. Это делает i18n/l10n гораздо проще с более установленными / принятыми методами. Может быть одним меньше http-вызова для некоторого существенного контекста, необходимого для рендеринга страниц, таких как пользователь, язык, валюта и т. д. Таким образом, обработка на стороне сервера увеличивается с рендерингом, но, возможно, компенсируется меньшим количеством http-вызовов на сервер API.

теперь, когда страницы отображаются на сервере, интерфейс теперь больше связан с средой программирования. Это может быть даже не соображение для многих приложения.

Twitter дело

Как я понимаю, Twitter может выполнять свой первоначальный рендеринг страниц на сервере, но для обновления страниц у него все еще есть некоторые вызовы API и шаблоны на стороне клиента для управления DOM. Поэтому в таком случае у вас есть двойные шаблоны для обслуживания, что добавляет некоторые накладные расходы и сложность. Не все могут позволить себе этот вариант, в отличие от Twitter.

наш стек проекта

Я использую Python. Я использую JsonRPC 2.0 вместо ОСТАЛЬНОЕ. Я предлагаю отдохнуть, хотя мне нравится идея JsonRPC по разным причинам. Я использую библиотеки ниже. Кто-то, рассматривающий вариант 2/3, может найти его полезным.

мой вывод и рекомендация

3!.

все сказано, я успешно использовал вариант 2, но теперь склоняюсь к варианту 3 для некоторой простоты. Создание статических HTML-страниц со скриптом сборки и их обслуживание один из сверхбыстрых серверов, специализирующихся на обслуживании статических страниц, очень заманчив (Вариант 2).


мы выбрали #2 при создании gaug.es. Я работал над API (ruby, sinatra и т. д.) и мой бизнес-партнер, Стив Смит, работал над front-end (javascript client).

плюсы:

  1. быстро двигаться параллельно. Если бы я работал раньше Стива, я мог бы продолжать создавать API для новых функций. Если бы он работал раньше меня, он мог бы очень легко подделать API и создать пользовательский интерфейс.

  2. API бесплатно. Наличие открытого доступа к данным в вашем приложение быстро становится стандартной функцией. Если вы начинаете с API с нуля, вы получаете это бесплатно.

  3. четкое разделение. Лучше думать о вашем приложении как об API с клиентами. Конечно, первым и самым важным клиентом может быть веб-клиент, но он настраивает вас на простое создание других клиентов (iPhone, Android).

плюсы:

  1. Совместимость. Это больше связано с API, чем с вашим direct вопрос, но как только ваш API там, вы не можете просто сломать его или сломать всех своих клиентов два. Это не означает, что вы должны двигаться медленнее, но это означает, что вы должны часто делать две вещи одновременно. Добавление в API или новые поля в порядке, но изменение / удаление не должно выполняться без управления версиями.

Я больше не могу думать о минусах прямо сейчас.

заключение: клиент API + JS-это путь, если вы планируете выпустить API.

P. S. Я также рекомендуется полностью документировать API перед его выпуском. Процесс документирования Gaug.ES API действительно помог нам imp

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


Я предпочитаю идти по маршруту №2 и № 3. Главным образом потому, что #1 нарушает разделение и смешение всех видов материалов. В конце концов вы обнаружите необходимость иметь конечную точку API, которая не имеет соответствующей HTML-страницы/etc, и вы будете в крике с перемешанными конечными точками HTML и JSON в той же базе кода. Он превращается в долбаный беспорядок, даже если его MVP, вам придется переписать его в конце концов, потому что его так грязно, что его даже не стоит спасать.

иду с #2 или #3 позволяет вам полностью иметь API, который действует одинаково (по большей части) независимо. Это обеспечивает большую гибкость. Я не на 100% продан на Backbone/ember/whatever / etc.js только что. Я думаю, что это здорово, но, как мы видим с twitter, это не оптимально. НО... Twitter также является огромным зверем компании и имеет сотни миллионов пользователей. Таким образом, любое улучшение может иметь огромное влияние на итог в различных областях различных бизнес-единиц. Я думаю, что в решении есть нечто большее, чем только скорость, и они нас в это не впустят. Но это только мое мнение. Однако я не сбрасываю со счетов костяк и его конкурентов. Эти приложения отлично подходят для использования и очень чисты и очень отзывчивы (по большей части).

третий вариант также имеет некоторое действительное очарование. Здесь я буду следовать принципу Парето (правило 80/20) и иметь 20% вашей основной разметки (или наоборот), отображаемой на сервере, а затем иметь хороший клиент JS (backbone/etc), запускающий остальную его часть. Вы можете не связывайтесь 100% с REST api через клиент JS, но вы будете делать некоторую работу, если необходимо, чтобы сделать более суровый опыт лучше.

Я думаю, что это одна из тех проблем "это зависит", и ответ "это зависит" от того, что вы делаете, кому Вы служите и какой опыт вы хотите, чтобы они получили. Учитывая, что я думаю, что вы можете выбрать между 2 или 3 или гибрид из них.


в настоящее время я работаю над преобразованием огромной CMS из Варианта 1 в Вариант 3, и все идет хорошо. Мы решили сделать разметку на стороне сервера, потому что SEO для нас большое дело, и мы хотим, чтобы сайты хорошо работали на мобильных телефонах.

Я использую node.js для клиентского бэк-энда и нескольких модулей, чтобы помочь мне. Я несколько рано в этом процессе, но основа установлена, и это вопрос перехода к данным, гарантирующим, что все будет правильно. Вот что я использую:

  • Экспресс для фонда приложения.
    (https://github.com/visionmedia/express)
  • запрос на получение данных.
    (https://github.com/mikeal/request)
  • Шаблоны подчеркивания, которые отображаются на стороне сервера. Я повторно использую их на клиенте.
    (https://github.com/documentcloud/underscore)
  • UTML обертывает шаблоны подчеркивания, чтобы заставить их работать с Express.
    (https://github.com/mikefrey/utml)
  • авансом собирает шаблоны, и давайте вы выбрали, которые отправляются клиенту.
    (https://github.com/mrDarcyMurphy/upfront)
  • Express Expose передает извлеченные данные, некоторые модули и шаблоны на передний конец.
    (https://github.com/visionmedia/express-expose)
  • магистраль создает модели и представления на интерфейсе после проглатывания данных, которые были переданы вдоль.
    (https://github.com/documentcloud/backbone)

это ядро стека. Некоторые другие модули, которые я нашел полезными:

  • Флек (протокол HTTPS//GitHub-е. ком/трек/Флек)
  • момент (протоколы https//GitHub-е. ком/timrwood/минуту)
  • стилусом (протокол HTTPS//GitHub-е. ком/LearnBoost/стилус)
  • котик (протокол HTTPS//GitHub-е. ком/жир/котик)
    ...хотя я смотрю в grunt (https / / github.com / cowboy / grunt)
  • консоль трассировки (//github.com/LearnBoost/console-trace).

Нет, я не использую coffeescript.

этот вариант работает очень хорошо для меня. Модели на задней панели не существуют, потому что данные, которые мы получаем из API, хорошо структурированы, и я передаю их дословно на передний конец. Единственным исключением является наша модель макета, где я добавляю один атрибут, который делает рендеринг умнее и легче. Для этого я не использовал библиотеку причудливых моделей, просто функцию, которая добавляет то, что я нужно по инициализации и возвращает себе.

(извините за странные ссылки, я слишком много n00b для переполнения стека, чтобы позволить мне опубликовать столько)


мы используем следующий вариант #3: Создайте сервер REST API только для JSON. Создайте сервер веб-сайта HTML. Веб-сервер HTML не является, как в вашем варианте, клиентом сервера REST API. Вместо этого они равны. Недалеко от поверхности есть внутренний API, который обеспечивает функциональность, необходимую двум серверам.

мы не знаем ни одного прецедента, так что это своего рода эксперимент. До сих пор (собирается войти в бета-версию), это сработало довольно хорошо.


обычно я использую 2-й вариант, используя Rails для создания API и магистрали для JS-материалов. Вы даже можете получить панель администратора бесплатно, используя ActiveAdmin. Я отправил десятки мобильных приложений с таким бэкэндом. Однако это сильно зависит от того, является ли ваше приложение интерактивным или нет.

Я сделал презентацию по этому подходу в последний RubyDay.это: http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

для третьего варианта, чтобы получить отзывчивость 2-го, вы можете попробовать pajax как делает Github.


Я около 2 месяцев в 3-месячный проект, который принимает второй подход вы изложили здесь. Мы используем серверную часть RESTful API с магистралью.js спереди. Рули.js управляет шаблонами, а jQuery обрабатывает манипуляции AJAX и DOM. Для старых браузеров и поисковых пауков мы вернулись к рендерингу на стороне сервера, но мы используем те же HTML-шаблоны, что и интерфейс Handlebars с использованием Mozilla Rhino.

мы выбрали этот подход по многим причинам но очень осознают, что это немного рискованно, учитывая, что это еще не доказано в широком масштабе. Все равно, пока все идет довольно гладко.

до сих пор мы просто работали с одним API, но на следующем этапе проекта мы будем работать со вторым API. Первый предназначен для больших объемов данных, а второй действует больше как CMS через API.

наличие этих двух частей проекта, полностью независимых друг от друга, было ключевым соображением в выбор этой инфраструктуры. Если вы ищете архитектуру для объединения различных независимых ресурсов без каких-либо зависимостей, то этот подход стоит посмотреть.

боюсь, я не рубиновый парень, поэтому я не могу комментировать другие подходы. Иногда можно рискнуть. В других случаях лучше не рисковать. Вы будете работать над собой в зависимости от типа проекта.

удачи с вашим выбором здесь. Жаждет увидеть, что разделяют и другие.


Мне нравится #3, когда мой сайт не будет 100% CRUD-реализацией моих данных. Что еще не произошло.

Я предпочитаю Синатру и просто разделю приложение на несколько разных приложений для стойки с разными целями. Я сделаю приложение для стойки API, которое будет покрывать то, что мне нужно для API. Тогда, возможно, пользовательское приложение rack, которое представит мою веб-страницу. Иногда эта версия будет запрашивать API, если это необходимо, но обычно это просто касается сайта html.

Я не беспокоюсь об этом и просто делаю запрос слоя persistance со стороны пользователя, если мне это нужно. Я не слишком озабочен созданием полного разделения, поскольку они обычно в конечном итоге служат разным целям.

здесь очень простой пример использования нескольких приложений для одежды. Я добавил быстрый пример jquery, чтобы вы увидели, как он попадает в приложение API. Вы можете увидеть, как просто это может быть с sinatra и монтаж нескольких приложений стойки с различными цели.

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


некоторые отличные ответы здесь уже - я бы определенно рекомендовал #2 или #3-разделение хорошо концептуально, но и на практике.

может быть трудно предсказать такие вещи, как загрузка и шаблоны трафика на API, и клиенты, которые мы видим, которые обслуживают API независимо, имеют более легкое время подготовки и масштабирования. Если вам нужно сделать это с помощью шаблонов веб-доступа человека, это менее просто. Кроме того, использование API может привести к масштабированию намного быстрее, чем ваш веб-клиент, а затем вы можете видеть, куда направить свои усилия.

между #2 #3 это действительно зависит от ваших целей - я бы согласился, что #2, вероятно, будущее webapps - но, возможно, вы хотите что-то более простое, если этот канал будет только одним из многих!


для atyourservice.com.cy мы используем шаблоны на стороне сервера для страниц, особенно для покрытия части se. И использование API для взаимодействия после загрузки страницы. Поскольку наша структура является MVC, все функции контроллера дублируются на вывод json и вывод html. Шаблоны чисты и получают только объект. Это может быть преобразовано в шаблоны js за считанные секунды. Мы всегда поддерживаем шаблоны serverside и просто повторно обращаемся к js по запросу.


изоморфный рендеринг и прогрессивное улучшение. Именно к этому, я думаю, вы и стремились в третьем варианте.

изоморфные отображения означает использование того же шаблона для создания разметки на стороне сервера, что и в коде на стороне клиента. Выберите язык шаблонов с хорошими реализациями на стороне сервера и на стороне клиента. Создайте полностью испеченный html для ваших пользователей и отправьте его по проводу. Также используйте кэширование.

постепенное повышение средства начать выполнение на стороне клиента и рендеринга и прослушивания событий, как только вы получили все ресурсы загружены, и вы можете определить возможности клиента. Возврат к функциональной клиент-скриптовой функциональности, где это возможно, для доступности и обратной совместимости.

Да, конечно, напишите автономный JSON api для этой функциональности приложения. Но не заходите так далеко, что вы пишете api json для вещей, которые отлично работают как статические html-документы.


REST server + JavaScript-тяжелый клиент был принципом, которому я следовал в своей недавней работе.

сервер REST был реализован в узел.js + Экспресс + MongoDB (очень хорошая производительность письма) + Мангуст ODM (отлично подходит для моделирования данных, проверки включены) + CoffeeScript (Я бы пошел ES2015 сейчас), который хорошо работал для меня. Узел.js может быть относительно молодым по сравнению с другой возможной серверной стороной технологии, но это позволило мне написать solid API с интегрированными платежами.

я использовал Эмбер.js как JavaScript framework и большая часть логики приложения была выполнена в браузере. Я использовал Сасс (SCSS специально) для предварительной обработки CSS.

Эмбер зрелые основ, подкрепленных сильной общины. Это очень мощный фреймворк с большим количеством работы в последнее время сосредоточены на производительности, как бренд новый Теплится движок (вдохновленный React).

команда Ember Core находится в процессе разработки команда shutdown, который позволит вам выполнить логику JavaScript Ember на стороне сервера (узел.JS в частности) и отправить предварительно визуализированный HTML вашего приложения (который обычно запускается в браузере) пользователю. Это отлично подходит для SEO и пользовательского опыта, поскольку он не ждет так долго для отображения страницы.

Эмбер командной строки - это отличный инструмент, который поможет вам чтобы организовать ваш код, и он хорошо масштабируется с растущей кодовой базой. Ember также имеет свою собственную экосистему аддонов, и вы можете выбрать из множества Ember Аддоны. Вы можете легко захватить Bootstrap (в моем случае) или Foundation и добавить его в свое приложение.

чтобы не обслуживать все через Express, я решил использовать nginx для обслуживания изображений и JavaScript-тяжелого клиента. Использование прокси nginx было полезно в моем случае:

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: мне нравится разделение API & клиент. Умные люди говорят, что это путь. Отлично в теории. Кажется ультрасовременным и захватывающим.

Я могу сказать, что это также большой на практике. Еще одно преимущество разделения REST API заключается в том, что вы можете повторно использовать его позже для других приложений. В perfect world вы сможете использовать тот же REST API не только для веб-страницы, но и для мобильных приложений, если решите написать его.

Con: не так много прецедентов. Не так много примеров этого сделано что ж. Общественный примеры (twitter.com) чувствовать себя вялым и даже переключаться от этот подход.

все выглядит по-другому. Существует множество примеров использования REST API + многими клиентами.


Я решил пойти на архитектуру варианта №2 для Infiniforms, поскольку это отличный способ отделить пользовательский интерфейс от бизнес-логики.

преимуществом этого является то, что серверы API могут масштабироваться независимо от веб-серверов. Если у вас несколько клиентов, то веб-сайты не должны масштабироваться в той же степени, что и веб-серверы, поскольку некоторые клиентские помои основаны на телефоне / планшете или рабочем столе.

этот подход также дает вам хорошую базу для открытие API для пользователей, особенно если вы используете собственный API для предоставления всех функциональных возможностей веб-сайта.


очень хороший вопрос, и я удивлен, поскольку я думал, что это очень распространенная задача в настоящее время, так что у меня будет много ресурсов для этой проблемы, однако оказалось, что это не так.

мои мысли таковы: - Создайте модуль, который имеет общую логику между контроллерами API и контроллерами HTML без возврат JSON или рендеринга html и включить этот модуль в контроллер HTML и контроллер API, а затем сделать все, что вы хотите, так для пример:

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

Я пошел на гибридный подход, где мы используем Sinatra в качестве базы, ActiveRecord / Postgress и т. д., чтобы обслуживать маршруты страниц (тонкие шаблоны), выставляют API REST, который может использовать веб-приложение. В ранней разработке такие вещи, как заполнение опций выбора, выполняются с помощью помощников рендеринга в тонкий шаблон, но по мере приближения к производству это заменяется вызовом AJAX в REST API, поскольку мы начинаем больше заботиться о скорости загрузки страницы и т. д.

материал, который легко отобразить В Slim обрабатывается таким образом и прочее (заполнение форм, получение данных POST формы из jQuery.Проверка submitHandler etc, все abviously AJAX)

тестирование является проблемой. Прямо сейчас я в тупике попытка передать данные JSON в стойку:: test POST test.


Я лично предпочитаю вариант (3) в качестве решения. Он используется почти на всех сайтах, которые есть у моего бывшего (домашнего) работодателя. Это означает, что вы можете получить некоторые интерфейсные разработчики, которые знают все о Javascript, причудах браузера и тому подобном, чтобы закодировать ваш интерфейс. Им нужно только знать "curl xyz, и вы получите JSON", и они уходят.

между тем, ваши тяжелые бэк-энд ребята могут кодировать поставщиков Json. Этим ребятам вообще не нужно думать о презентации., и вместо этого беспокоиться о flaky бэкэндов, тайм-аутов, изящной обработки ошибок, пулов подключения к базе данных, потоков и масштабирования и т.д.

Вариант 3 дает вам хорошую, прочную трехуровневую архитектуру. Это означает, что материал, который вы выплевываете из переднего конца, является SEO-дружественным, может работать со старыми или новыми браузерами (и теми, у которых JS выключен), и все еще может быть шаблоном на стороне клиента Javascript, если вы хотите (так что вы можете делать такие вещи, как обрабатывать старые браузеры/googlebot со статическим HTML, но отправлять JS построил динамический опыт для людей, использующих последний браузер Chrome или что-то еще).

во всех случаях, когда я видел Вариант 3, это была пользовательская реализация некоторого PHP, который не особенно переносится между проектами, не говоря уже о том, чтобы открыть исходный код. Я думаю, что в последнее время PHP, возможно, был заменен Ruby/Rails, но то же самое по-прежнему верно.

FWIW, $current_employer может сделать с вариантом 3 в нескольких важных местах. Я ищу хорошая структура Ruby, в которой можно что-то построить. Я уверен, что могу склеить кучу драгоценных камней, но я бы предпочел один продукт, который широко предоставляет шаблон, "завиток", необязательную аутентификацию, необязательное решение кэширования memcache/nosql. Там я не могу найти ничего связного : - (


создание API JSON в Rails-это первый класс, драгоценный камень Jsonapi::Resources делает тяжелый подъем для http://jsonapi.org spec'D API.