Подтвердить что ты не робот

Как создать REST API с помощью Rails 3.0?

Я не могу найти много информации в Интернете о различных подходах к созданию REST API в Rails; поэтому у меня есть два вопроса:

  • Может кто-нибудь указать мне на некоторые статьи, которые показывают плюсы/минусы разных подходы?
  • Не могли бы вы поделиться своими мыслями о плюсах и минусах следующих подходов?

 

Предлагаемые подходы

 

  • Используйте стандартные контроллеры для возврата XML, когда пользователи добавят .xml в конец  URL

    Плюсы:

    • Это встроенный в Rails и очень простой в использовании
    • Выполняет тот же подход на основе ресурсов, что и Rails, поэтому для него будет легко существующие пользователи, чтобы понять/запомнить

    Минусы:

    • API не полностью отделен от основного сайта, сложнее поддерживать
    • Люди могут предположить, что добавление .xml будет работать в местах, где это не

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

    Плюсы:

    • API в основном разделен.
    • Все еще использует полнофункциональные контроллеры

    Минусы:

    • URL-адреса имеют форму site.com/api/resource.xml, которые могут заставить людей принять все ресурсы доступны
    • API все еще является частью кода/проекта веб-сайта; таким образом, сложнее поддерживать

  • Использовать перенаправление маршрутов и ограничения для перенаправления всех вызовов API на стойку  приложение

    Плюсы:

    • API полностью разделен
    • Не требуется использовать ресурсо-полный стиль, если мы не хотим
    • URL-адреса ясно показывают его API, и вы должны проверить документы, чтобы узнать, что доступно (по крайней мере, мой ум работает таким образом, я полагаю, что другие умы разума тоже)

    Минусы:

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

4b9b3361

ОТВЕТЫ

Ответ 1

Я бы предположил, что API, находящийся в том же проекте, что и ваш сайт, не так уж плох, пока код DRY *. Как вы указали, наличие отдельных кодовых баз является проблемой, потому что вы должны синхронизировать их со всеми функциями/исправлениями, которые вы делаете. Это легче поддерживать, если они находятся в одном месте. Пока вы держите свой код DRY, этот метод является явным победителем.

Я бы предложил XML и JSON из контроллеров с субдоменом, обработанным движком Rails. Когда кто-то подхватил образец api.site.com/resource.xml и пытается получить доступ к ресурсу, которого там нет, это действительно не очень важно. До тех пор, пока ваш API будет документирован четко и вы будете ошибочно/ошибочно ошибочно, когда они попытаются получить доступ к ресурсу, не входящему в ваш API, все должно быть хорошо. Я попытаюсь вернуть сообщение о том, что ресурс недоступен, и URL-адрес вашей документации api. Это не должно быть проблемой времени выполнения для любых пользователей API, поскольку это должно быть частью обнаружения вашего API.

Только мои $0,02.



* DRY = Не повторяйте себя. Код DRY означает, что вы не копируете-вставляете и не переписываете одно и то же для своего сайта и своего api; вы извлекаете и вызываете из нескольких мест.

Ответ 2

Я думаю, что лучшим решением для вас является объединение ваших первых двух точек.

Я предлагаю использовать JSON вместо XML: единственным аргументом в пользу XML является XPath, который бесполезен в возвращенных данных. JSON обеспечивает лучшее время отклика (и более читаемые данные для лучшей отладки!). P). Кроме того, большинство языков могут читать JSON. Например, PHP может естественным образом анализировать JSON для массива/объекта с помощью json_decode, поэтому это хорошая точка.;)

Для контроллеров вы можете их пропустить, но это не обязательство, возможно, в некоторых случаях лучше избегать жирных действий с множеством условий. С маршрутизатором Rails 3 разделение вызовов API в субдомене (api.webapp.com) тривиально).

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

Новый синтаксис маршрутизатора rails - это сахар, вам понравится. Удачи и приятного времяпровождения!:)