Taknado

Перевод (подробности здесь) статьи REST 101: Part 2 – A Million APIs, автором которой является Jeff Cohen.

В предыдущей статье я пытался убедить Вас в том, что WEB – это совокупность ресурсов, а не WEB-страниц. Сегодня мы еще на шаг приблизимся к пониманию REST.

Объектно ориентированный подход

Если Вы когда-либо занимались ООП, то скорее всего действовали примерно по такому плану:

1. Необходимо описать, что будет делать Ваша программа.
2. Существительные в получившимся описании – это классы.
3. Глаголы – это методы классов.
4. Для того чтобы программа решала поставленную задача необходимо, чтобы существительные вызывали методы других существительных.

Звучит разумно, и именно так я программировал долгое время. Такой подход часто называется “RPC”-стилем. Я не совсем понимаю причем здесь “удаленность” (RPC – Remote Procedure Call – Удаленный вызов процедур), но знаю, что это является традиционным способом проектирования объектно-ориентированных программ. Это отличный способ, но WEB работает не так. Почему?

Представьте, что на сейчас 1992 год и 3 крупных компании разработали 3 разных онлайн программных продукта: один для покупки книг, другой для бронирования авиабилетов и третий для просмотра аэрофотографий, сделанных в воздухе над Землей. Каждая из компаний создавала свой продукт используя классический объектно-ориентированный подход, описанный выше. Они так-же предусмотрели возможность использования своих продуктов другими приложениями, реализовав для каждого свой собственный API.

Теперь представьте что Ваша задача – создать инструмент, который использовал бы все эти 3 приложения одновременно.

Вам пришлось бы изучить 3 различных API и я готов поспорить что у Вас были бы элементы пользовательского интерфейса, напрямую взаимодействующие с методами этих API. Но этого звучит логично, так? Как бы еще Вы могли это сделать? К тому же, API всего три и Вы, конечно, знаете несколько хороших книг из которых можно почерпнуть паттерны для того тобы упростить архитектуру (и выглядеть круто в глазах сослуживцев). Но что если бы Вам пришлось иметь дело с миллионами API?

Давайте вновь вспомним о браузере. Когда Вы устанавливаете его на на свой компьютер, он не обладает данными о том, какие сайты Вы собираетесь посещать. Он способен отображать любой сайт который Вы заходите, и более того, с его помощью Вы можете покупать музыку, бронировать авиабилеты и рассматривать свой дом на фотографиях из космоса.

Это магия? Задумайтесь над тем, как обстояло бы дело, если бы у каждого сайта был свой API. Для того чтобы купить книгу на Amazon браузеру необходимо было бы уметь вызывать Amazon.Buy(), а когда я нажимал бы кнопку “Просмотреть список авиарейсов”, обращаться к UnitedAirlines.CheckFlights(). Совершенно невозможно создать инструмент, котрый бы использовал миллионы различных API.

Именно поэтому WEB не основывается на RPC. В основе архитектуры WEB лежат ресурсы, т.е. REST.

Согласно Wikipedia, REST – это Representational State Transfer. Чтобы это не значило, смысл в том, что вместо существительных со своим определенным набором глаголов, каждое существительное (с текущего момента будем называть их ресурсами) обладает одним и тем же конечным набором глаголов (т.е. конечный список действий, которые над ними можно произвести). Другими словами у всех ресурсов единый API. Основные методы API позволяют любому клиенту:

1. Получить ресурс только для чтения.
2. Создать новый ресурс.
3. Обновить существующий ресурс.
4. Удалить ресурс.

Но постойте! Каким из этих методов я смогу “купить книгу”? Каким “найти авиарейсы из Чикаго в Нью-Йорк в следующий вторник”? Каким изменить масштаб карты с уровня “города” до уровня “улицы”? Какой из этих методов позволит посетителю авторизироваться на сайте?

На эти вопросы мы ответим в следующий раз. Но я думаю, что, возможно, у Вас уже есть ответы, если вы действительно перестали думать о “покупке книги” как о WEB-странице и пытаетесь определить какой ресурс используется Вами в этом случае. До встречи.