Ответ 1

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

Плюсы:

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

Минусы:

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

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

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

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

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

UPDATE:

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

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

Ответ 2

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

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

Вариант 1

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

Вариант 2

Я всегда любил это.

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

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

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

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

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

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

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

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

Вариант 3

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

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

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

Случай Twitter

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

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

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

• Сервер API: Python Быстрая сетевая инфраструктура - Flask
• Сервер Frontend: Nginx
• Клиентская сторона MVC: Knockout.js
• Другие соответствующие инструменты/библиотеки:
  • Jquery
  • Accounting.js для денежной валюты
  • Webshim: Кросс-браузер polyfill
  • director: Маршрутизация на стороне клиента
  • sphc: генерация HTML

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

Вариант 3!.

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

Ответ 3

Мы выбрали # 2 при создании gaug.es. Я работал над API (рубин, синатра и т.д.), А мой бизнес-партнер Стив Смит работал над интерфейсом (javascript-клиент).

Плюсы:

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

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

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

Минусы:

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

Я не могу больше думать об этом.

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

• fleck (https//github.com/trek/fleck)
• moment (https//github.com/timrwood/moment)
• stylus (https//github.com/LearnBoost/stylus)
• smoosh (https//github.com/fat/smoosh)
  ... хотя я ищу хрюкать (https//github.com/cowboy/grunt)
• console trace (//github.com/LearnBoost/console-trace).

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

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

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

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

Ответ 9

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

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

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

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

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

Ответ 10

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

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

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

Ответ 11

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

Ответ 12

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

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

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

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

Ответ 13

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

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

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

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

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

Ember CLI - отличный инструмент, который поможет вам организовать свой код, и он хорошо справился с ростом с растущей базой кода. У Ember также есть собственная экосистема аддона, и вы можете выбрать из множества Ember Addons. Вы можете легко захватить 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 заключается в том, что вы можете повторно использовать его позже для других приложений. В идеальном мире вы должны иметь возможность использовать один и тот же REST API не только для веб-страницы, но и для мобильных приложений, если вы решите написать ее.

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

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

Ответ 14

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

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

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

Ответ 15

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

Мои мысли таковы: - Создайте модуль с общей логикой между контроллерами 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

Ответ 16

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

Вещи, которые легко визуализировать в Slim, обрабатываются таким образом, и материал (заполнение форм, получение форм POST-данных из jQuery.Validation submitHandler и т.д., все это явно AJAX)

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

Ответ 17

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

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

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

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

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

Ответ 18

Построение JSON API в Rails является первым классом, JSONAPI:: Resources gem делает тяжелый подъем для http://jsonapi.org spec ' d API.