Нужно ли создавать отдельную конечную точку API для мобильных приложений для доступа к веб-приложению Rails?

У меня есть веб-приложение, реализованное в Ruby on Rails 4, для этого требуется собственное приложение для Android, я действительно новичок в разработке мобильных приложений.

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

1) Мне действительно нужен отдельный API для мобильного приложения? в чем проблемы с использованием существующих контроллеров Rails с помощью respond_to format.json?

2) Я видел некоторые онлайн-примеры, которые предлагают использовать отдельное пространство имен API в приложении Rails для обслуживания мобильных запросов, например class Api::ApiController < ActionController::Base для нового контроллера, а затем добавить namespace :api do в routes.rb. С этим подходом, разве это не означает, что мне нужно будет дублировать совсем немного функций моего контроллера в этом новом пространстве имен только для мобильных устройств?

3) Что касается аутентификации, многие примеры предлагают использовать аутентификацию по токенам, встроенная система управления сеансами Rails недостаточно хороша для мобильных приложений? или это потому, что cookie сеанса работает совершенно по-другому в мобильном приложении?

Оцените свое время.

Ответ 1

Это не обязательно, но, как вы сказали, считается лучшей практикой.

1 + 2) Наличие одинаковых контроллеров с логикой response_to/reply_with - это хорошая идея с первого взгляда. Но, по моему опыту, могу сказать, всегда наступает день, когда код API начинает отличаться кодом HTML-клиента. У мобильного клиента может быть другой пользовательский интерфейс, и вполне естественно, что он будет использовать ваши данные другим способом, как это делает ваш веб-клиент. Веб-клиент специализирован для одного варианта использования, когда API должен быть более общим, позволяющим использовать несколько способов потребления.

Вторая проблема, которая возникнет, заключается в том, что вы не можете полагаться на своих мобильных пользователей, чтобы всегда иметь последнюю версию приложения, где с помощью webapp вы можете. Таким образом, для приложения HTML вы можете легко вводить несовместимые изменения, потому что вы доставляете правильный клиент прямо там, где для мобильного API, нарушающего API, по крайней мере. Возможно, вы захотите сохранить обратную совместимость, которая сделает ваши универсальные контроллеры уродливыми, как черт. И без правильного пространства имен api/v1 вы даже не можете иметь две разные версии API одновременно.

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

3) У вашего мобильного HTTP lib с высокой вероятностью есть правильное автоматическое управление файлами cookie. Наличие аутентификации на основе токенов - это снова лучшая практика. Если это всего лишь токен vs session_id в cookie, выигрыша не будет. Я могу только думать, что он будет автоматически защищен от атаки CSRF, и вы можете полностью отключить эту защиту для API, потому что пользователям вашего сайта не будет разрешено использовать API, просто введя его на сайт (возможно, дополнительное преимущество), При аутентификации на основе сеанса вам придется сгенерировать токен CSRF при первом запросе API и установить его в X-CSRF-Token cookie.

Большим преимуществом проверки подлинности на токенах является то, что он расширяется до большей безопасности, например, вводит токены истечения, токены HMAC и т.д., в которых аутентификация сеанса не является. См. Использование сеансов против токенов для проверки подлинности API

Я также рекомендую вам посмотреть json: api. Он исходит от создателей ember.js, которые думали о том, чтобы принимать решения о принятии решений при создании API-интерфейсов. Еще одна интересная вещь - active_model_serializers gem. Вступление к нему дано в Rails: следующие пять лет от Yehuda Katz