REST Ликбез. Часть 3. Проектирование согласно REST.
August 1st, 2007
Перевод (подробности здесь) статьи Rest 101: Part 3 – RESTful Design, автором которой является Jeff Cohen.
Ранее мы обсуждали разницу между WEB-страницей и ресурсом. Сегодня нам предстоит понять как архитектура, основанная на ресурсах, может быть нам полезна.
С текущего момента считайте свое приложение не более чем хранилищем ресурсов. Что такое хранилище? SVN – хороший пример хранилища исходных кодов. MySQL – хранилище реляционных данных. Позиция хоккейной команды Chicago в турнирной таблице NHL – это доступное только для чтения хранилище некоторой хоккейной статистики.
Сейчас мне нужно придумать хранилище ресурсов, которое я буду использовать в качестве примера в этой статье.
Допустим Вы работаете в Softies TransAir и Вам поручили создать программную инфраструктуру компаниии с нуля.
1. Вам необходим инструмент для занесения информации об авиарейсах. Авиарейс – это самолет перемещающийся из одного города в другой в определенное время. 2. Вам необходим WEB интерфейс для сотрудников аэропорта. Вы также хотите, чтобы пассажиры могли проверить статус рейса с мобильного телефоны 3. Ваш начальник хочет, чтобы Вы реализовали XML-API, который мог бы быть использован сторонними разработчиками для реализации обновления данных на тех самых огромных щитах в здании аэропорта.
Интересный проект, не так ли? Помните как ранее мы обсуждали традиционный объектно-ориентированный подход? Согласно ему можно взглянуть на описание задачи и выделить существительные (которые в последствии станут объектами) и глаголы (которые станут методами). Только представьте сколько замечательных паттернов вы могли бы здесь применить! Я знаю, Вам просто не терпится нарисовать огромную UML диаграмму на доске вместе с несколькими диаграммами взаимодействия! И Вы уже видите реализованными методы вроде FlightSchedule.CancelFlight() и Flight.Delay().
Уж простите. Поскольку Вы решили идти дорогой REST, то большая часть архитектуры уже продумана за Вас. По сути все что Вам остается сделать, это определить ресурсы.
И пожалуй я повторю на тот случай если Вы не услышали меня за шуршанием своих маркеров по доске потому что это действительно важно.
Просто определите ресурсы.
В нашем примере я могу сразу выделить несколько ключевых существительных: самолеты, аэропорты и авиарейсы. Возможно со временем появятся еще, но для начала этого достаточно.
Каким образом клиентское приложение будет обращатсья ко всем этим ресурсам? Для это были изобретены URL (Кстати, вы же знаете что означает L в URL?) Идентификатор каждого ресурса построен по простому шаблону. Например:
/airports – список аэропортов /airplanes – список самолетов /flights – список авиарейсов
и:
/airports/ord – аэропорт Chicago O’Hare /airplanes/ZJ3543 – самолет с серйиным номером ZJ3543 /flights/451 – авиарейс #451
Четыре метода
Хорошо, Вы определились с ресурсами. REST в свою очередь предлагает четыре метода (глагола – если проводить параллель с ООП), которые каждый из Ваших ресурсов может имплементировать.
GET. Я хочу получить представление одного из ресурсов в режиме только чтения. POST. У меня есть новый ресурс который я хочу добавить в хранилище. PUT. Я хочу обновить ресурс который уже присутствует в хранилище. DELETE. Я хочу удалить ресурс из хранилища.
Ничего не напоминает? В SVN GET – это команда ‘checkout’ или ‘update’. POST – это команда ‘add’. PUT это команда ‘commit’. ‘DELETE – это собственно команда ‘delete’. Если сравнить с MySQL, GET – это запрос SELECT, POST – это INSERT, PUT – это UPDATE и DELETE – снова просто DELETE.
Теперь когда мы определились с ресурсами и методами можно заканчивать проектирование и переходить к реализации.
Вызов методов при помощи HTTP
В WEB-приложениях в качестве средства обмена данными между сервером и клиентом используется HTTP. Теперь мы можем подкорректировать неточное описание того, как работает браузер, данное в первой части. Что же происходит на самом деле когда мы набираем URL в адресной строке? Браузер составляет HTTP запрос для вызова метода GET ресурса, идентифицируемого по URL, который мы ввели.
Вы так же можете вызвать метод POST, но только в том случае, если на странице есть форма (Да, не совсем так, благо есть AJAX, но давайте пока остановимся на этом). Формы могут отправлять данные по определенному URL. Когда вы подтверждаете отправку формы, браузер вызывает метод POST у ресурса, расположенного по URL и передает ему данные, которые являются значениями атрибутов ресурса который он хочет создать или обновить.
К сожалению Вы не можете вызвать PUT или DELETE стандартными средствами HTML. Тем не менее каждый HTTP сервер в мире готов принять вызов этих методов и для того чтобы их вызвать необходимо придумать некий способ показать серверу что Вы пытаетесь обратиться к PUT или DELETE.
Таким образом Вы можете связать свой REST API с типами запросов HTTP, но из-за того что средствами HTML нельзя заставить браузер делать запросы PUT и DELETE, сервер и клиент должны договориться о том, как они они будут эмулировать вызов этих методов.
В этой статье мы завершили проектирование и в следующий раз перейдем непосредственно к написанию кода.
August 6th, 2007 at 08:39 AM > Е_лс_и сравнить с MySQL, GET – это запрос SELECT, POST – это INSERT, PUT – это UPDATE и DELETE – снова просто DELETE.
August 7th, 2007 at 08:26 PM Спасибо, отличный перевод. Жду продолжения!
December 19th, 2007 at 04:00 PM В тексте опечатка: которое мы я буду использовать
April 23rd, 2008 at 01:24 PM >> Кстати, вы же знаете что означает L в URL? URL - *U*niform *R*esource *L*ocator Может-таки *R*? ;)