Зовут меня Роман и я RESTоман +1



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


С REST похожая ситуация. Он дает некие патерны проектирования высоконагруженных систем. Используя его, ты получаешь вполне сносные системы. Это генерирует серотонин (гормон счастья), что закрепляет связь REST = счастье. Со временем тебе нужно все больше REST… чтобы эйфория сохранялась на прежнем уровне.


Когда я подсел на REST? Вопрос хороший… первую “дозу” я хапнул, когда мне было около 17 лет. Это был кажется 1997г. Адепты REST сразу заметили, наверное, что в 1997 году не было REST. Но это не так. Термина, да, не существовал. Но кайф мы получали уже тогда. Кто как умел. И надо сказать, что торкало куда как круче чем сегодня.


C ajax были тоже проблемы. Его не было. Про SPA даже не мечтали. Но у меня возникла мысль — при таком медленном линке, логичнее загружать ту часть страницы, которая требует обновления. А не всю. Вполне обычная, рядовая мысль. Ее заурядность переоценить невозможно. Она всем тогда приходила.


Небольшой исторический экскурс. Интерактивность в Интернет тогда все же была. В те времена бушевали страсти в html чатах. Чат представлял собой три фрейма. В одном был список контактов, в другом диалог, в третьем ты писал что-то.


Все фреймы рефрешились через стандартный мета html. Как-то так:


<meta http-equiv=refresh content=5>

Т.е. у тебя постоянно мелькал какой-то фрейм. Это позволяло видеть новые сообщения, которые отдавал сервер в виде готового html (сервер-рендеринг, котаны!). Недостатки описывать не буду, они очевидны.



Я подумал — а нельзя это как-то более плавно сделать? Думаю, это был мой первый ajax, но я этого не знал еще почти 10 лет.


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


Это была не одна проблема. Возвращать контент нужно было в html. А далее парсить DOM чтобы что-то достать. Т.ч. плавность хоть и появлялась, но удобства не было. А уж POST запрос с ним отправить было вообще тяжко.


Стоит отметить, что в те времена VBScript был чуть ли не популярнее чем JavaScript. А точнее JScript. И я писал, конечно, на VBScript.



Следующим моим подходом стало написание applet на java. Тоже уже забытая технология, но она позволяла встраивать микроприложения Java в страницу браузера. Ныне покойный Netscape особенно хорошо ее поддерживал.



Мне удалось сделать нечто вроде XMLHttpRequest. Конечно его функциональность была далека от XMLHttpRequest, но выглядело это круто. Я наконец смог в наших проектах сделать нечто сильно облегчающее трафик.


Т.к. проекты были интерпрайзные, то вполне можно было указывать требования к развертыванию. Ты просто говорил, что все браузеры в конторе должны поддерживать этот аплет. Т.ч. никакой фантастики. Мир я не изменил. Но это была моя первая доза. Я начал делать нечто сильно напоминающего REST запросы из браузера.


На тот момент моя технология уже соответствовала некоторым требованиям REST:


  1. Модель клиент-сервер;
  2. Кэширование;
  3. Слои;
  4. Код по требованию.

Достаточно быстро я пришел к проблеме унифицированного обмена между клиентом и серверам. Т.е. к требованию №4 — Единообразие интерфейса.


Я отправлял запросы через GET и POST. Ответом мне был CVS. Он парсился аплетом и отдавался в виде массива, который уже разбирался скриптом. Это неплохо работало. Работало потому, что была простая трансляция в реляционные таблицы вставок через POST и отдача результата селектов через GET.


В общем-то вышел аля тонкий клиент, который знал об устройстве БД и поэтому мог через HTTP с ней общаться.


Проблема возникла при создании ссылок. При выводе результата очередного селекта, формировалась ссылка, которая содержала GET параметры классифицирующие и идентифицирующие объект. Также определялось представление в котором он должен вернуться. Это было сложно. Рендеринг на стороне клиента занимал время. Напомню шел 1997-2000гг. Клиентские машины не отличались производительностью.


Тогда я решил в ответы запихивать уже готовые GET ссылки. Так, нечаянно я пришел к URI. И тут попер гипертекст… это была вторая доза. Теперь сервер манипулировал клиентом через гипертекст. Т.е. я достиг просветления пункта №4 требований REST. Но вот до пункта №2 (отсутствие состояния) я тогда не дошел. Скажем так, не было проблем, которые требовалось решать в этом контексте.


В 2000х годах, технология ajax сделала свой широкий шаг навстречу всем нам. Но, эта история показывает, что то, что приобрело термин не придумывалось в тот же день, как возник сам термин. Более того, термин это то, что классифицировало и описывало то, что уже есть. Мы ждали этого слова. И оно возникло. REST. Теперь так называлась та дурь, на которой я сидел.



Но дурь Роя, отличалась о той, что “мы” использовали. Поэтому, была введена классификация дури. Если дурь полностью соответствует дури Роя, то это RESTful, если не полностью, то это REST.


Это не значит, что дурь Роя лучше. Это значит, что дурь Роя хорошая дурь, которую может повторить каждый на своей кухне. Но мы то знаем...


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


Ваш RESTоман.




К сожалению, не доступен сервер mySQL