Как мне создать REST API с использованием Rails 3.0?
Я могу ' Похоже, в Интернете можно найти много информации о различных подходах к созданию REST API в Rails; поэтому у меня есть два вопроса:
- Может кто-нибудь указать мне на некоторые статьи, которые показывают плюсы / минусы различных approaches?
- Would you please share your thoughts on the pros/cons of the following approaches?
Proposed Approaches
Use the standard controllers to return XML when a users adds
.xmlto the end of the URLPros:
- This is built-in to Rails and very easy to use
- Follows the same resource-based approach that Rails has, so it will be easy for
existing users to understand/remember
Cons:
- API isn't cleanly separated from the main site, harder to maintain
- People may assume that adding
.xmlwill work in places it doesn't
Use namespaced routing to create separate API controllers that only handle API функций, но все еще имеют доступ к тем же моделям, которые использует веб-сайт
Плюсы:
- API в основном разделены
- По-прежнему используются контроллеры с полным ресурсом
Минусы:
- URL-адреса имеют форму сайта. com / api / resource.xml, который может заставить людей принять на себя все ресурсы доступны
- API все еще является частью кода сайта / проекта; таким образом, сложнее поддерживать
Использовать переадресацию маршрута и ограничения для переадресации всех вызовов API в Rack application
Плюсы:
- API полностью отделен
- Не требуется использовать стиль с полным ресурсом, если мы не хотим, чтобы
- URL-адреса четко отображали, что это API, и вы должны проверить документы, чтобы увидеть, что доступно (по крайней мере, мой разум работает таким образом; я полагаю, что и у других разработчиков тоже)
Минусы:
- Труднее использовать модели из кода сайта
- Легче поддерживать как отдельный проект, но это труднее интегрировать с участием существующий сайт
- Необходимо синхронизировать базы кода, поскольку модели могут изменяться для функций сайта / исправления ошибок
2 ответа
Я бы предположил, что API в том же проекте, что и ваш веб-сайт, не так уж плохо, если код СУХОЙ*. Как вы заметили, иметь отдельные кодовые базы — это проблема, потому что вы должны синхронизировать их с каждой функцией/исправлением, которые вы делаете. Легче поддерживать, если они находятся в одном и том же месте. Пока вы сохраняете свой код СУХИМ, этот метод является явным победителем.
Я бы предложил XML и JSON от контроллеров с поддоменом, обрабатываемым механизмом маршрутизации Rails. Когда кто-то подхватил шаблон api.site.com/resource.xml и пытается получить доступ к ресурсу, которого там нет, это не имеет большого значения. Пока ваш API четко задокументирован, и вы корректно терпите неудачу/ошибку, когда они пытаются получить доступ к ресурсу не в вашем API, все должно быть в порядке. Я бы попытался вернуть сообщение о том, что ресурс недоступен, и ссылку на вашу документацию по API. Это не должно быть проблемой во время выполнения для любых потребителей API, так как это должно быть частью обнаружения вашего API.
Только мои 0,02 доллара.
*DRY = Не повторяйся. СУХОЙ код означает, что вы не копируете и не переписываете одно и то же для своего сайта и API; вы извлекаете и вызываете из нескольких мест.
Я думаю, что лучшим решением для вас будет объединить первые два пункта.
Я предлагаю использовать JSON вместо XML: единственный довод в пользу XML — это XPath, который бесполезен для возвращаемых данных. JSON приводит к лучшему времени отклика (и более читаемым данным для лучшей отладки! :p). Кроме того, большинство языков могут читать JSON. Например, PHP может изначально анализировать JSON в массив/объект с помощью json_decode, так что это хороший момент. ;)
Для контроллеров вы можете использовать пространство имен, но это не обязательно, возможно, в некоторых случаях лучше избегать жирных действий с кучей условий. С маршрутизатором Rails 3 разделение вызовов API в поддомене (api.webapp.com) тривиально).
Для модели, конечно, вы должны использовать то же, что и во всем приложении.
Новый синтаксис rails router — это сахар, вам понравится. Удачи повеселиться! :)