REST - это стиль дизайна для протоколов, он был разработан Роем Филдингом в его докторской диссертации и формализовал подход к HTTP / 1.0, нахождение того, что хорошо с ним работает, а затем использование этого более структурированного понимания, чтобы повлиять на дизайн HTTP / 1.1. Итак, хотя во многих отношениях это было запоздалым, REST - это стиль разработки HTTP.
диссертацию Филдинга можно найти по адресу http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm, и она очень стоит прочитать, а также очень читабельна. Кандидатские диссертации могут быть довольно трудоемкими, но эта статья чудесно хорошо описана и очень читаема для тех из нас, у кого нет сопоставимого уровня информатики. Помогает, что сам REST довольно прост; это одна из тех вещей, которые становятся очевидными после того, как кто-то еще придумал это. (В этом отношении также заключено в себе множество вещей, которые пожилые веб-разработчики усвоили на собственном опыте в одном простом стиле, что сделало его чтение важным моментом «ха!» Для многих).
Другие протоколы уровня приложений, а также HTTP также могут использовать REST, но классический пример - HTTP.
Поскольку HTTP использует REST, все виды использования HTTP используют систему REST. Описание веб-приложения или службы как RESTful или не-RESTful относится к тому, использует ли оно REST или работает против него.
Классическим примером системы RESTful является «простой» веб-сайт без файлов cookie (файлы cookie не всегда противоречат REST, но они могут быть): состояние клиента изменяется пользователем, щелкающим ссылку, которая загружает другую страницу, или делать запросы GET формы, которая приносит результаты. Запросы формы POST могут изменить состояние сервера и клиента (сервер делает что-то на основе POST, а затем отправляет гипертекстовый документ, описывающий новое состояние). URI описывают ресурсы, но сущность (документ), описывающая его, может отличаться в зависимости от типа контента или языка, предпочитаемого пользователем. Наконец, браузеры всегда могли обновить саму страницу с помощью PUT и DELETE, хотя это никогда не было распространенным явлением, а теперь, если что-то не так.
Классический пример системы без RESTful, использующей HTTP, - это то, что обрабатывает HTTP, как если бы это был транспортный протокол, и с каждым запросом отправляет POST данных на тот же URI, который затем обрабатывается в RPC-подобном таким образом, возможно, с самим соединением, имеющим общее состояние.
RESTful-машиночитаемая система (т.е. не веб-сайт в браузере, а что-то используемое программно) получит информацию о ресурсах, связанных с GETting URI, которая затем вернет документ (например, в XML, но не обязательно), который будет описать состояние ресурса, включая URI для связанных ресурсов (следовательно, гипермедиа), изменить их состояние с помощью объектов PUTting, описывающих новое состояние, или УДАЛИТЬ их, а также выполнить другие действия, выполняемые POSTing.
Ключевые преимущества:
Масштабируемость. Отсутствие общего состояния делает систему гораздо более масштабируемой (я продемонстрировал это в массовом порядке, когда я полностью исключил использование состояния сеанса из сильно пострадавшего веб-сайта, хотя я ожидал, что он даст немного дополнительной производительности, даже давний защитник сессий, такой как я, был поражен огромной выгодой от удаления того, что было довольно скудным использованием сессий, даже я не убрал их!)
Простота: есть несколько различных способов, которыми REST проще, чем более RPC-подобные модели, в частности, есть только несколько «глаголов», которые когда-либо возможны, и каждый тип ресурса может быть рассмотрен в разумной изоляции. другим.
Облегченные сущности. Более RPC-подобные модели, как правило, заканчиваются большим количеством данных в сущностях, отправляемых обоими способами, просто чтобы отразить RPC-подобную модель. Это не нужно Действительно, иногда простой текстовый документ - это все, что действительно необходимо в данном случае, и в этом случае с REST это все, что нам нужно отправить (хотя это будет только случай с «конечным результатом», так как обычный текст не ссылается на связанные ресурсы). Другим классическим примером является запрос на получение файла изображения. RPC-подобные модели обычно должны переносить его в другой формат и, возможно, кодировать его каким-либо образом, чтобы оставить его в родительском формате (например, если RPC-подобная модель использует XML , изображение должно быть в формате base-64 или аналогично, чтобы соответствовать действительному XML). Модель RESTful просто передает файл так же, как и в браузер.
Результаты, читаемые человеком: не обязательно так, но часто легко создать веб-сервис RESTful, где результаты относительно легко читаются, что помогает отладке и разработке без конца. Я даже построил такой, где XSLT означал, что все это может быть использовано людьми как (относительно грубый) веб-сайт, хотя это было не в первую очередь для использования человеком (по сути, XSLT служил в качестве клиента, чтобы представить его пользователи, это даже не было в спецификации, просто сделано, чтобы облегчить мою собственную разработку!).
Более слабая привязка между сервером и клиентом: упрощает последующую разработку или изменяет расположение системы. Действительно, если вы будете придерживаться гипертекстовой модели, вы можете изменить всю структуру, включая переход с одного хоста на несколько хостов для разных сервисов, без изменения кода клиента вообще.
Кэширование. Для операций GET, когда клиент получает информацию о состоянии ресурса, стандартные механизмы кэширования HTTP допускают оба утверждения, которые не будут значимо изменяться до определенной даты в ближайшее время (нет необходимости запрашивать в все до тех пор) или что это не изменилось со времени последнего запроса (отправьте пару сотен байтов заголовков, сообщающих об этом, а не несколько килобайт данных). Улучшение производительности может быть огромным (достаточно большим, чтобы переместить производительность чего-либо из точки, в которой его использование практически нецелесообразно, в точку, где производительность больше не является проблемой, в некоторых случаях).
Доступность наборов инструментов: поскольку он работает на относительно простом уровне, если у вас есть веб-сервер, вы можете создать сервер системы RESTful и если у вас есть какой-либо HTTP-клиент API (XHR в браузерном JavaScript, HttpWebRequest в .NET и т. Д. ) вы можете создать клиент системы RESTful.
Устойчивость. В частности, отсутствие общего состояния означает, что клиент может умереть и вернуться в строй без ведома сервера, и даже сервер может умереть и вернуться в строй без ведома клиента. Очевидно, что в этот период связь будет прервана, но как только сервер вернется в оперативный режим, все может продолжиться, как было. Это также действительно упрощает использование веб-ферм для обеспечения избыточности и производительности - каждый сервер действует так, как будто это единственный сервер, и не имеет значения, что он фактически обрабатывает только часть запросов от данного клиента.