Как мне создать REST API с использованием Rails 3.0?

Question

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

1. Может кто-нибудь указать мне на некоторые статьи, которые показывают плюсы / минусы различных подходов?
2. Будет лиПожалуйста, поделитесь своими мыслями о плюсах / минусах следующих подходов?

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

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

   Плюсы:

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

   Минусы:

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

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

   Плюсы:

   • API в основном разделен
   • По-прежнему используются контроллеры, заполненные ресурсами

   Минусы:

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

3. Использовать переадресацию маршрута и ограничения для переадресации всех вызовов API в приложение Rack

   Плюсы:

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

   Минусы:

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

Answer 1

Я бы предложил, чтобы API, находящийся в том же проекте, что и ваш сайт, не был плохим, если код СУХОЙ *.Как вы указали, наличие отдельных кодовых баз является проблемой, потому что вы должны поддерживать их синхронизацию с каждой функцией / исправлением, которое вы делаете.Проще поддерживать, если они в одном месте.Пока вы сохраняете свой код СУХИМЫМ, этот метод является явным победителем.

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

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

* СУХОЙ = Не повторяйся.СУХОЙ код означает, что вы не копируете и не переписываете одно и то же для своего сайта и API;Вы извлекаете и звоните из нескольких мест.

Answer 2

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

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

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

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

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