Ответ 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