RESTful Rails. Часть I

RESTful Rails был очень обсуждаемой частью ядра Rails, так как оригинальный плагин restful_rails был включен в ядро ​​чуть более года назад. Но с улучшениями, которые были сделаны в Rails 2.0, они здесь, чтобы остаться, поэтому важно понять, что они, как они работают и когда (а когда нет) их использовать. Это на самом деле довольно большая тема, и я думаю, что стоит сначала дать вам некоторую предысторию, поэтому я разделю пост на две части — часть I теоретическая, часть II практическая. Так что наденьте шляпы сетевого протокола и будьте готовы узнать о внутренней работе языка Интернета.

ОТДЫХ против CRUD

Где будет сеть без аббревиатур? REST обозначает RE презентационный Sate T Transfer и описывает ресурсы (в нашем случае URL), над которыми мы можем выполнять действия . CRUD , что означает C reate, R ead, U pdate, D elete, — это те действия, которые мы выполняем. Хотя в Rails REST и CRUD являются лучшими друзьями, оба могут отлично работать самостоятельно. Фактически, каждый раз, когда вы писали бэкэнд-систему, которая позволяет вам добавлять, редактировать и удалять элементы из базы данных, и интерфейс, который позволяет вам просматривать эти элементы, вы работали с CRUD.

HTTP-глаголы

Любой веб-разработчик, которому приходилось иметь дело с данными формы, знал бы о методах GET и POST. Первый отправляет данные обратно на сервер через строку запроса, которая выглядит примерно так: key2 = value2 & key2 = value2, а вторая отправляет данные через HTTP-заголовки. Что вы можете не понимать, так это то, что каждый раз, когда вы загружаете страницу (это не форма типа POST), вы делаете запрос GET. Поэтому, когда вы нажали на ссылку в вашем RSS-ридере, который купил вас здесь, вы сделали запрос GET.

Есть два других глагола, о которых вы, возможно, не слышали, потому что браузеры их не поддерживают: PUT и DELETE. Действие удаления очевидно — если указывает серверу что-то удалить. Инструкция PUT немного более загадочна — она ​​аналогична действию POST с точки зрения отправки данных через заголовки, но она предназначена для изменения чего-либо (она также должна создавать новый объект, если объект не уже существует, но Rails игнорирует этот минор технически).

Более проницательные из вас, возможно, заметили, что GET очень похож на READ, POST выглядит как CREATE, PUT — то же самое, что UPDATE, а DELETE — DELETE. Если вы это сделали, переходите прямо к главе класса — это именно та корреляция, которую использует Rails при работе с RESTful-рельсами.

Коды ответа HTTP

Все знают, что если вы попытаетесь получить доступ к несуществующей странице, сервер вернет вам страницу, которая не найдена , или если вы испортите свой код rails, вы получите 500 Ошибка приложения . Это коды ответов, которые сервер отправляет обратно, чтобы ваш браузер знал, что происходит. Что-то между 200-299 означает, что запрос был успешным, 300-399 означает, что запрос был в порядке, но вам нужно сделать что-то еще, 400-499 — это ошибка, а 500-599 — действительно плохая ошибка. Так же, как есть глаголы, соответствующие запросам RESTful, существуют коды ответов, которые соответствуют ответам RESTful.

200 ОК

Вы получите запрос GET, PUT или DELETE. Это означает, что запрос проверен и соответствующие действия приняты

201 Создано

Уведомляет вас, что команда POST успешно создала опубликованный объект.

404 Не Найдено

Означает, что ресурс запроса не найден. Вы можете получить это из GET, PUT или DELETE.

406 Недопустимо

Глагол недопустим в ресурсах, которые вы запросили (подробнее об этом в следующей части)

внутренняя ошибка сервера 500

Что-то пошло не так

Ресурсы

Вы бы привыкли видеть URL-адреса Rails, которые выглядят примерно как / posts / view / 2 — что примерно соответствует «Пожалуйста, дайте мне просмотреть сообщение с идентификатором № 2». Ресурсы RESTful очень похожи в том, что у них есть контроллер и (возможно) и идентификатор. Чего они обычно не имеют, так это действия, потому что оно присуще глаголу HTTP.

Чтобы сделать это, команда Rails определила ряд специальных методов в контроллерах, которые определяют ресурсы — в этом случае сообщения (бит .xml станет понятным в следующей части).

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

Итак, в следующей части мы рассмотрим, как создать проект RESTful rails и как все соединить. До тех пор…