REPRESENTATIONAL STATE TRANSFER. ВВЕДЕНИЕ В ТЕХНОЛОГИЮ

REPRESENTATIONAL STATE TRANSFER. ВВЕДЕНИЕ В

ТЕХНОЛОГИЮ Марк Б.И.

Марк Богдан Игоревич - студент, кафедра информатика и вычислительная техника,

Сибирский федеральный университет автоматизированные системы обработки информации и управления, г. Красноярск

Аннотация: REST (Representational State Transfer) — это способ создания API с помощью протокола HTTP. На русском языке его называют «передачей состояния представления». Автор статьи описывает технологию на простых примерах для понимания начинающих обучение в сфере IT.

Ключевые слова: REST, API, HTTP.

Representational State Transfer или сокращенно REST. Что же это такое. В интернете полно статей, на разных языках о том, что это. Но многие трактовки этого понятия противоречат друг другу. Как же докопаться до сути.

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

Еще не плохой способ - коли информации имеется много, можно изучить ее большую часть, пускай даже если она противоречит другой. Когда мы изучим несколько точек зрения, можно их сравнить, пораскинуть немного своими мозгами, и выявить какую-нибудь одну свою, и дальше придерживаться её.

Для этого придется разобрать несколько примеров. Ах да, примеров... Без них примеров, конечно, никуда. Очень многие вещи нам зачастую помогают понимать именно примеры.

Пускай точка зрения, описанная в этой статье, будет дополнением к тем которые Вы уже изучили, или Вам еще предстоит изучить. Я буду использовать как можно меньше технических терминов, о них достаточно уже написано. Здесь я постараюсь изложить свое видение основных концепций связанных с REST на простых примерах. Для того что бы в дальнейшем, при изучении Вами технической документации, процесс понимания сложных веще был чуточку приятней. И если вдруг Вам останется, что-то не понятно, возможно все прояснится как раз таки в дальнейшем, при изучении REST уже на реальных примерах.

Кодекс разработчика

Самое распространенное и ключевое понятие REST — это стиль. Стиль взаимодействия распределенного web приложения (или сложного, составного приложения).

Давайте немного поговорим об этом самом web приложении, и где оно там распределено. В обычной жизни приложением для нас является программка, скачанная на телефон или на планшет. Программа на рабочем компьютере. Или некоторые web сайты в интернете сейчас все чаще называют web версией приложения. Получается, что приложение это - приложение на телефоне, планшете или сайт в интернете? Да это является приложением, но зачастую - это всего лишь часть. Часть одного большого приложения, состоящего из нескольких таких частей.

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

Сами данные берутся из скрытой от пользователя части приложения, которую называют серверной. Вся обработка и хранение информации происходит там. Серверная часть приложения может так же делиться на части, состоять из нескольких приложений (серверов). Именно поэтому распределенное веб приложение и называют сложным. А распределенным оно считается, потому что территориально его компоненты могут находиться абсолютно в разных местах.

Со сложным распределенным приложение немного разобрались. Теперь давайте разбираться со стилем. Что это за стиль такой REST. Существует стиль в одежде, архитектурный стиль, музыкальный стиль и так далее. И что между всем этим общего? А то, что в любом стиле есть свои правила, как этому стилю соответствовать. И собственно совокупность этих правил и называют стилем. Т.е. получается, что и REST — это совокупность правил? В точку! REST это совокупность правил организации взаимодействия тех самых компонентов распределённого приложения, о которых мы говорили выше. Что-то вроде кодекса, написанного разработчиками для разработчиков.

Отлично, с терминами мы разобрались. Осталось разобраться, что это за правила такие.

Индейка в сливочном соусе.

Представьте себе, что вы приходите в ресторан, садитесь за столик и вот вы готовы сделать заказ. К Вам подходит официант, и Вы сообщаете ему что

на горячее Вы будете индейку в сливочном соусе, на десерт пирожное с черносливом, а пить вы будете лимонный компот. Не плохой выбор! Официант внимательно выслушивает Вас и удаляется на кухню. Там он в свою очередь сообщает повару, что тот должен приготовить для Вас жаркое из индейки, пирожное с черносливом и компот.

Спустя какое-то время, официант возвращается к Вам и приносит Ваши блюда.

Все это здорово, но, казалось бы, причем здесь REST? Давайте рассмотрим все что произошло выше, как будто Вы воспользовались приложением (сложным приложением) разработанному по всем канонам REST, далее мы будем называть его REST системой.

И так, Вы хотите что-то получить от официанта, назовем это что-то -ресурс. Для этого вы обращаетесь к официанту, как бы запрашивая у него этот ресурс. Другими словами, делаете запрос. И, стало быть, если вы запрашиваете у официанта этот ресурс, значит он у него есть. В системе REST, тот кто запрашивает ресурс называется клиентом, тот кто имеет этот ресурс называется сервером.

Получается, Вы являетесь клиентом, официант сервером. Вы передаете ему запрос, в котором указываете какую еду Вы бы хотели сегодня отведать

(получить в ответ). Представим сам запрос вот в таком формате.

{

"горячее": "индейка в сливочном соусе", "десерт": "пирожное с черносливом", "напиток": "лимонный компот"

}

Так гораздо лучше. Передавать запрос Вы будете по url-адресу:

ЬН:р://ресторан/официант/прием заказов

Отлично, ну и теперь сразу же, давайте коснемся методов передачи запросов. Методом является одно ключевое слово, в начале запроса, которое указывает какое действие с желаемым ресурсом вы бы хотели произвести. В данном случае, т.к. вы еще и сами передаете какую-то информацию, методом передачи запроса будет метод POST. Подробнее о запросах, а точнее об их методах, мы поговорим чуть позже. А пока имеем запрос такого вида:

Адрес: кйр://ресторан/официант/заказ;

Метод: POST;

Тело запроса:

{

"горячее": "индейка в сливочном соусе", "десерт": "пирожное с черносливом", "напиток": "лимонный компот"

};

Официант обрабатывает данные, и передает их дальше - повару, так же в виде запроса. Здесь, уже официант берет на себя роль клиентом, а повар является сервером. Давайте представим это в виде наглядной схемы.

Как мы видим, на схеме есть клиенты и есть серверы. Тут сразу же стоит отметить, что речь идет о ролях компонентов системы, обращающихся друг к другу. И не в коем случае нельзя отождествлять понятия клиента и сервера с клиентской и серверной частью приложения. В данном случае клиентской частью будет посетитель ресторана (крайний левый клиент). Все что правее

- серверная часть.

Вот так выглядит схема работы приложения, построенного по принципу клиент-серверной архитектуры. А мы с вами имеем, первое правило организации REST, это клиент-сервер. Есть клиент, есть сервер. Они взаимодействуют между забой путем отправки запроса и получения ответа.

Наверное, Вы заметили, что на схеме присутствует еще и база данных. В сложных приложениях так называют хранилище данных. Конечно, перед тем как начать готовить Вам еду, повар должен заглянуть в холодильник и убедиться в том, что у него есть все необходимые продукты. Тут холодильник будет являться базой данных, и только повар может взаимодействовать с ней. Тут мы с вами подошли ко второму правилу REST

- многослойная архитектура.

Могло бы оказаться так, что в холодильнике не оказалось бы нужных продуктов и тогда бы повар на запрос официанта вернул бы вместо готового блюда свои сожаления, которые официант в свою очередь передал бы Вам. Ему бы пришлось предложить Вам что-нибудь другое, поуговаривать Вас остаться, чтобы вы сделали новый заказ. Причем, заметьте, клиент может взаимодействовать только со своим сервером, а сервер со своим клиентом. Повар не выйдет к Вам в гостевой зал и не сообщит Вам плохую новость лично. И его абсолютно не волнует, как дальше пойдет взаимодействие у Вас с официантом. Продуктов нет и все тут, дальше не его вотчина. Вот же нахал... В этом и заключается особенность такая особенность REST как слоистая архитектура.

Рис. 1. Наглядная схема.

Но, все-таки предположим, что сегодня все сложилось удачно, все продукты оказались в холодильнике (базе данных), и официант вернул вам положительный ответ в виде горячего и компота, а не сожалений. Тут вроде бы все понятно, идем дальше.

Ну и запросы у Вас ...

Теперь давайте подробнее разберемся с нашими запросами, а точнее с методами их передачи. Что это за методы такие. Придется немного пофантазировать.

Оставшись довольны трапезой, Вы решили вернуться в это заведение в следующий выходной. Неделя, на удивление, пролетела очень быстро, и вот Вы снова сидите за столиком. А номер Вашего столика, предположим - 4. Почему бы и нет? К Вам подходит официант и Вы делаете заказ. Снова представим его в виде запроса:

Адрес: кйр://ресторан/официант/заказ;

Метод: POST;

Тело запроса:

{

"горячее": "индейка в сливочном соусе", "десерт": "пирожное с черносливом", "напиток": "лимонный компот"

};

Теперь давайте более детально проанализируем, что же происходит дальше. Официант принимает Ваш запрос, и формирует новый запрос, для отправки дальше - повару. Этот запрос уже будет выглядеть следующим образом:

Адрес: кйр://ресторан/повар/заказы;

Метод: POST;

Тело запроса:

{

"заказ для": "столик №4",

"заказ": {

"горячее": "индейка в сливочном соусе", "десерт": "пирожное с черносливом",

"напиток": "лимонный компот" }

};

Особо внимательный заметит, что в конце адреса, по которому передает свой запрос официант указано - заказы, во множественном числе. Это и правильно, ведь посетителей ресторана много, как и заказов. Но как официанту с поваром ориентироваться во всех этих заказах? Для этого в запросе официанта добавился еще и номер Вашего столика. Это поле будет

неким идентификатором или ID заказа. После чего, будет создан некий ресурс (заказ), доступный по адресу:

кН:р://ресторан/повар/заказы/заказ_для_столика_№4 И все дальнейшие манипуляции с этим заказом, будут происходить именно по этому адресу.

Пока официант был на кухне передавая данные повару, Вы вспоминаете, что один Ваш приятель рассказывал Вам про чудесный суп с грибами, который он ел в этом ресторане. Как только в следующий раз официант попадает к Вам в поле зрения, Вы подзываете его к себе и сообщаете, что очень хотели бы попробовать еще и суп. Тут переданный Вами запрос будет иметь следующий вид:

Адрес: кйр://ресторан/официант/заказ; Метод: PATCH;

Тело запроса: {

"первое блюдо": "грибной суп",

};

Метод этого запроса будет - PATCH. Тем самым будет понятно, что к уже имеющемуся заказу, нужно добавить первое блюдо. Теперь официант как-то должен донести до повара информацию о том, что Вам нужно приготовить еще и суп. Как это сделать? Конечно же отправить запрос. Но этот запрос будет уже немного другим.

Адрес: кйр://ресторан/повар/заказы/заказ_для_столика_№4; Метод: PATCH;

Тело запроса: {

"первое блюдо": "грибной суп",

};

Адрес отправки запроса уже будет следующий: кН:р://ресторан/повар/заказы/заказ_для_столика_№4 Вот для чего нам нужен был ID заказа. Когда официант будет передавать данные повару, ему будет понятно, что речь идет об уже имеющемся заказе для столика №4.

Отлично, теперь повар поймет, что ему нужно приготовить суп и отдать его официанту, обслуживающему столик №4.

Ну что ж, повар приступил к приготовлению, но Вы немного поразмысли поняли, что грибной суп — это не совсем то, чего бы Вам сегодня хотелось. Что с гораздо большем аппетитом Вы бы съели суп с говядиной. И, пожалуй, при таком раскладе пирожное с черносливом уже не поместится в Вашем желудке. Придется опять изменять заказ. Не беда, в этом заведении Вы можете себе такое позволить. Легкий жест рукой и официант снова у Вашего столика, готовый выслушать Ваши новые пожелания. В этой ситуации придется уже сделать два запроса.

Первый, методом PATCH для изменения первого блюда: Адрес: кйр://ресторан/официант/заказ; Метод: PATCH;

Тело запроса: {

"первое блюдо": "суп с говядиной"

};

Второй, еще не знакомым нам методом DELETE для отмены десерта: Адрес: кйр://ресторан/официант/заказ; Метод: DELETE;

Тело запроса: {

"десерт": "пирожное с черносливом"

};

Отлично, Вы отказались от десерта, и перезаказали суп. Теперь Вы точно останетесь довольны ужином.

Официант же, спешит на кухню сообщить повару, чтобы тот не торопился класть в суп грибы. Там он также может передать два запроса повару: Первый:

Адрес: кН:р://ресторан/повар/заказы/заказ_для_столика_.№4; Метод: PATCH;

Тело запроса: {

"первое блюдо": "суп с говядиной"

};

Второй:

Адрес: кН:р://ресторан/повар/заказы/заказ_для_столика_.№4; Метод: DELETE;

Тело запроса: {

"десерт": "пирожное с черносливом"

};

Но есть и альтернативный вариант. Тут то и появляется на сцене еще один метод - PUT. Метод PUT может целиком заменить уже имеющийся ресурс, в нашем случае речь идет о заказе.

И так, официант обращается по адресу: кН:р://ресторан/повар/заказы/заказ_для_столика_.№4;

И методом PUT передает запрос: {

"первое блюдо": "суп с говядиной", "горячее": "индейка в сливочном соусе", "напиток": "лимонный компот"

};

Отлично. Старый заказ будет удален, а вместо него появится новый. Теперь повар поймет, что для столика №4 ему не нужно готовить пирожное. А вместо шампиньонов в суп он положит свежую говядину.

Существует так же метод GET, пример с ним мы рассмотрим чуть позже. На самом деле методов запросов существует больше. Мы рассмотрели только самые основные.

Что ж, и в этот раз все блюда Вам благополучно были доставлены. Вы остались довольны, и конечно же решили вернуться сюда, в следующий свой выходной.

На самом деле в этой главе мы рассмотрели не только методы передачи запроса, но еще и коснулись одного из самых главных правил REST это -единого интерфейса. Это правило достойно отдельной главы, поэтому о нем мы поговорим дальше.

Один как все и все как один

И так, единый интерфейс. Что это? В данном случае, слово интерфейс можно отождествить как способ взаимодействия. Т.е. дальше речь пойдет о едином способе взаимодействия. Конечно же, в контексте REST взаимодействия компонентов приложения, которыми как мы уже говорили являются клиент и сервер. Хм, что мы имеем теперь? Одно из правил REST-единый интерфейс - это правило единого способа взаимодействия компонентов приложения. А само понятие REST это совокупность правил организации взаимодействия тех самых компонентов распределённого приложения. Т.е. получается, что одно из набора правил взаимодействия -это правило взаимодействия. Масло масленое. Умозаключение конечно логичное, но смысловой нагрузки пока в себе не несет никакой. Давайте разбираться.

Вернемся к нашему вежливому официанту. Как мы уже сказали, совокупности правил взаимодействия REST, есть отдельное правило общения, которое так и называется правило взаимодействия. Официант компонент системы? Компонент. Значит и для него применимо это правило. Мы уже коснулись ролей взаимодействия, зон ответственности, но еще не говорили о поведении. Да, единый интерфейс - это что-то вроде правила поведения во время взаимодействия. Дак как же должен вести себя наш официант? Он должен быть учтив, внимателен, вежлив. Он должен знать кому и что ему можно и нужно говорить. Когда он подойдет к Вашему столику, он предложит Вам сделать заказ и не начнет рассказывать Вам о том, как правильно играть в гольф, или как готовить круассаны с клубникой. Ему совершенно не важно, кто будет его клиентом. С любым своим клиентом он будет взаимодействовать одинаково учтиво - выслушивать заказ, вежливо отвечать на вопросы, приносить еду и напитки. Так же повару - неважно для какого столика он будет готовить еду, какой официант принес ему заказ. Повар будет стараться приготовить одинаково для всех.

В этом и есть прелесть REST. Компоненты REST системы стандартизированы, их можно легко заменить другими такими же компонентами, главное, чтобы они знали, как им взаимодействовать друг с другом. Если вдруг посещаемость ресторана будет расти, можно увеличь количество официантов. Ведь правила поведения официантов везде одинаковые. Нужно только показать новенькому официанту где кухня, и он готов к работе. При этом другие элементы системы, затронуты не будут, и никой работы над ними проделывать не нужно.

Представим еще, что наш любимый ресторан стал предлагать такую услугу как - еда на вынос. Тут потребуются новые компоненты -доставщики еды. Они будут общаться с клиентской частью по средством телефонной связи или мессенджеров, но передавать заказ повару они будут абсолютно так же, как и официанты. Отправлять запрос:

Адрес: кйр://ресторан/повар/заказы;

Метод: POST;

Тело запроса:

{

"заказ для": "доставщик Иван Иванов",

"заказ": {

"горячее": "индейка в сливочном соусе", "десерт": "пирожное с черносливом",

"напиток": "лимонный компот" }

};

Тем самым создавая ресурс:

ЬНр://ресторан/повар/заказы/заказ на вынос Иван Иванов;

Процесс изменения размеров системы называется - масштабированием. Масштабирование - это один из неотъемлемых плюсов REST систем. В любой момент можно легко изменять размеры серверной части, в зависимости от потребностей клиентской. И во многом это благодаря правилу единого поведения. Замечательное правило! О нем еще так же стоит сказать, что само оно включает четыре подправила, для того чтобы было проще следовать ему.

Первое - ресурсоемкость или ресурсный подход.

Суть этого правила заключается в том, хоть у каждого ресурса и есть свой идентификатор (заказ_для_столика_№4) он должен быть включен в обобщенное понятие (заказы), для того чтобы мы знали к какой группе ресурсов относится это ресурс.

Второе - манипуляция ресурсами посредством представлений.

Я бы даже сказал посредством перепредставлений, или если быть еще точнее перепредоставлений. В оригинале это правило называется

Manipulation of Resources Through Representations. Сама аббревиатура REST - Representational State Transfer. И самое важное тут понять, что же это за Representations и Representational.

Representations - переводится как представление. У клиента есть свое представление о ресурсе. Оно может меняться. Как мы помним из нашего примера, мы могли несколько раз изменять свой заказ. Для этого мы озвучивали свое представление того, как должен выглядеть наш заказ официанту, а тот в свою очередь повару.

Тогда что же такое Representational? В контексте с REST, пожалуй, можно дать значение этому слову - актуальный или наиболее точный.

Из чего следует, что REST можно перевести как - передача актуального состояния.

Но тут стоит отметить - изменять ресурс может только тот у которого есть на это право. Официант, обслуживающий столики № 3, 4 и 7 не может прийти к повару и изменить заказ для столика № 1.

Третье - информативные сообщения.

Когда клиент обращается к серверу он должен быть абсолютно точным в своих обращениях.

Если за столиком №3 кто-то закажет моккачино, официант не должен придя к повару крикнуть ему: «Мне моккачино, и побыстрее!». Повар может подумать, что официант устал и хочет выпить кофе дабы восполнить силы. На скорую руку он сварит не самый лучший в его практике напиток, положит туда побольше кофе, дабы заряда бодрости официанту хватило на подольше. Да и еще нальет все это в железную большую кружку, т.к. чистой чашки под рукой не окажется.

Вместо этого официант должен прийти к повару и сказать: «Заказ для третьего столика. Моккачино.» Вот тогда повар правильно поймет официанта. Приготовит свой лучший напиток и нальет его в чистую фарфоровую чашку.

Четвертое - гипермедиа как движущая сила состояния приложения. Hypermedia as the Engine of Application State или сокращенно (HATEOAS). Об этом правиле давайте поговорим чуть позже.

Официант не был бы официантом будь у него состояние.

В каждый Ваш приход в ресторан, Ваше общение с официантом начинается с чистого листа. У Вас не получится сказать ему: «Я буду тоже, что и в прошлый раз». Официант не запоминает кто и что заказывал в прошлый свой приход. Поэтому если Вы захотите повторить свой заказ, Вам придется потратить немного времени и снова озвучить весь список желаемого. Это и будет называться Stateless или отсутствием состояния, что в свою очередь является еще одним правилом REST. Может это конечно не очень удобно для клиента, помнить, что он заказывал в прошлый раз приходится именно ему. Да и времени, чтобы повторять свой заказ снова,

уйдет гораздо больше, нежели просто скажи Вы: «Мне как обычно!». Но, давайте вспомним о том, что официант обычно обслуживающий Ваш столик, хоть и добросовестный работник, но все же человек, и может попросту заболеть. И его заменит другой. И вот он, этот другой официант, уже точно не будет помнить, что Вы там ели в прошлый раз. Ему не придется звонить официанту, который обслуживал Вас в прошлый раз и узнавать Ваш прошлый заказ. Пока тот вспомнит... Да и телефона может не оказаться под рукой. Гораздо проще и быстрее будет если официант просто запишет Ваш заказ и отнесет повару, согласитесь? А если в следующий Ваш приход и это официант не выйдет на работу по каким-то причинам, его с легкостью заменит любой другой, который будет не занят. Это еще один критерий, благодаря которому возможно масштабирование масштабированием.

Поскольку заказ Вам придется делать по новой, Вы решили изучить меню. Ваше внимание привлек салат с сельдереем. Подозвав официанта, Вы решили поинтересоваться у него, с чем же этот салат.

Вы снова делаете запрос, но в этот раз уже долгожданным методом GET. Ведь в этот раз, Вы сами уже не передаете никаких данных. Выглядеть это будет примерно так:

Адрес: https://ресторан/официант/составы блюд/салат с сельдереем; Метод: GET

Как видите, тут уже нет никакого тела запроса. Мы хотим получить информацию ничего не передав. А то, относительно чего мы хотим получить информацию, мы указываем в адресной строке.

Теперь официанту нужно дать вам ответ, в виде рецепта салата. Официант, к сожалению, не знает рецепта. Он удаляется на кухню, чтобы поинтересоваться у повара - из чего же тот готовит этот салат. И спустя

какое-то время официант возвращает Вам ответ: {

"салат с сельдереем": "курица, сельдерей, перепелиное яйцо,

оливковое масло" }

Такой себе салат, не правда ли? Но о вкусах не спорят, хоть Вы этот салат решили не заказывать, а вот за соседнем столиком, кто-то услышала про этот салат, и тоже решил поинтересоваться у официанта, из чего-же готовят этот салат. Официант опять удаляется на кухню, он уже забыл рецепт. Ах этот неряшливый официант. Но повар твердо знает, что он кладет в свой салат, и спустя время официант возвращается к клиенту с рецептом салата. Салат с сельдереем становится все популярнее. Теперь уже в другом конце зала, кто-то решил попробовать салат с сельдереем. И вот официант снова направляется на кухню, чтобы узнать рецепт. Согласитесь не самая лучшая ситуация? Какой же может быть выход из нее. Пожалуй, рецепт салата, это неизменяемые данные, или не так часто изменяемые. Поэтому официанту вполне было бы не плохо запомнить его. Тогда он сможет озвучивать

клиентам рецепт салата мгновенно, не тратя свое время на походы на кухню, да и повара не будет отвлекать почем зря. Запоминание рецепта салата в этой ситуации будет называться кэшированием. Кэширование — это еще одно правило REST.

Но тут стоит отметить одну особенность. Кэшировать стоит только те данные, которые точно не изменятся, а если вдруг они поменяются, то нужно так же перезаписать их в кэше.

Вдруг у повара не окажется курицы, и он решит добавить в салат вместо нее рыбу. Согласитесь, будет не очень хорошо, если гостю принесут салат с рыбой, в то время как официант пообещает ему салат с курицей.

Теперь давайте вернемся к пропущенному понятию HATEOAS. Придя в какое-нибудь заведение, и поинтересуйся там рецептом салата, официант в ответ сообщил бы вам только рецепт, и ничего более. Но в этой статье мы рассматриваем заведение, где взаимодействие компонентов происходит согласно всем правилам REST. И что это будет значить Вас?

Когда Вы поинтересуетесь у официанта из чего же будет приготовлен салат, в ответ Вы услышите не только сам рецепт салата, но и то, какое еще блюдо Вы можете заказать в дополнение к этому салату, с каким напитком его лучше попробовать. А также другие блюда, которые Вы бы могли попробовать, не окажись этого салата в наличии. Или информацию о тех блюдах, о которых по мнению официанта, Вам очень важно было бы знать.

Согласно правилу HATEOAS, сервер в ответ на запрос возвращает не только запрошенную информацию или ресурс, но и отсылки к другим ресурсам, чтобы клиент мог в них ориентироваться.

Не плохо правда? Теперь Вы можете заказать, что-то еще. Или вообще изменить свой заказ. Вроде бы это хорошее правило, но не всегда оно работает во благо. Сильно расторопный клиент может глубоко задуматься, что же теперь ему стоит заказать. Выбор окажется настолько мучительным, что чтобы его сделать потребуется много времени. Поэтому тут, официанту стоит все же хорошо подумать прежде, чем формировать свой ответ.

Официант, дичь!

И снова Вы в своем любимом ресторане. В этот раз Вы заказали не жаркое из индейки, а блюдо из дикой куропатки. Особенность этого блюда в том, что его нужно есть с пылу с жару. Как же этого добиться? Ведь пока официант дойдет до повара, пока принесет блюдо Вам. А если в этот момент будет занят обслуживанием другого столика... Пройдет много времени, блюдо остынет. К счастью для Вас гении кулинарного дела придумали выход - заливать блюдо алкоголем и поджигать. Отличное решение, но согласитесь следовать официанту через весь зал с горящей куропаткой не самое лучшее решение. Хм. А ведь можно просто снабдить официанта всем необходимым, скажем - блюдом залитым алкоголем и спичками, и поджиг выполнить уже непосредственно в момент подачи, скажем так - на стороне клиента.

Подобным образом и работает последнее правило REST - код по запросу. Допустим нам нужно выполнить какой-то сценарий на стороне клиента. Не обязательно выполнять его еще и на сервере, не правда ли? Можно отправить код на клиентскую часть приложения, и там уже выполнить его. Примерно так же, как поджечь куропатку под носом у клиента. Подведем итоги

Что ж, мы выяснили, что для того, чтобы организовать REST сервис, необходимо придерживаться следующих шести правил:

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

2. Слоистая архитектура. Клиентов и серверов может быть много. Промежуточные элементы являются как клиентом для своего сервера, так и сервером для своего клиента. Каждый клиент может общаться только со своим сервером, а сервер со своим клиентом. Клиент не может общаться с сервером своего сервера. Помните, повар не принесет Вам жаркое сам лично.

3. Единый интерфейс. Способ общения компонентов обозначен определенным стандартом, манерами поведения.

4. Никто не хранит состояние. Новый сеанс общения - чистый лист.

5. Кэширование. Все-таки какую-то часто используемую информацию хранить можно.

6. Код по запросу. Если нужно выполнить сценарий на стороне клиента, можно предоставить ему для этого все необходимое, пускай выполняет...

И так, система REST это распределенное в сети приложение, спроектированное согласно кодексу REST. Хоть кодекс это и не свод жестких законов, а правил, нарушать эти правила нельзя. Разве что есть одно не обязательное к исполнению правило - код по запросу.

Теперь обладая общими представлениями о REST, Вы можете приступить к изучению технической документации по этой теме, чтобы понимать работу системы в реальных ситуациях.

Список литературы

1. Акинин Ю. Р., Барабанов А. В., Гребенникова Н. И. Быстрое создание Rest API сервиса на основе облачных технологий Azure // Вестник ВГТУ 2012. №12-1. URL: https://cyberlenmka.ru/article/n/bystroe-sozdanie-rest-api-servisa-na-osnove-oblachnyh-tehnologiy-azure (дата обращения: 28.01.2024).

2. Безрук П.А. Разработка системы распределенного мониторинга компьютерной сети на основе rest API // Актуальные проблемы авиации и космонавтики. 2017. №13. URL: https://cyberleninka.ru/article/n/razrabotka-

sistemy-raspredelennogo-monitoringa-kompyuternoy-seti-na-osnove-rest-api (дата обращения: 28.01.2024).