Чем отличается http запрос от rest запросов

Что такое REST API?

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

Что такое API

В общем, API (Application Programming Interface) обеспечивает взаимодействие между двумя системами. Это как винтик, связывающий две детали, или как шестеренка, при помощи которой приводятся в движение две соседние шестеренки (как на картинке ниже).

apigear

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

calc

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

В конечном счете, разработчики вызывают API незримо для пользователя для извлечения информации в свои приложения. Кнопка в графическом интерфейсе пользователя программно подключена для вызова внешних служб. Например, кнопки Twitter или Facebook, которые взаимодействуют с социальными сетями, или видео Youtube, которые извлекают видео с youtube.com, работают под управлением веб-API.

API, использующие протокол HTTP = веб-сервисы

«Веб-сервис» — это веб-приложение, предоставляющее ресурсы в формате, используемом другими компьютерами. Веб-сервисы включают в себя различные типы API, в том числе REST и SOAP API. Веб-сервисы — это, в основном, запросы и ответы между клиентами и серверами (компьютер запрашивает ресурс, а веб-сервис отвечает на запрос).

API, использующие протокол HTTP для передачи запросов и ответов, рассматриваются как «веб-сервисы». В случае веб-сервисов клиент, делающий запрос на ресурс, и сервер API, предоставляющий ответ, могут использовать любой язык программирования или платформу. Не имеет значения, какой ЯП или платформа будут использоваться, потому что запрос сообщения и ответ сделаны через общий веб-протокол HTTP.

Веб-протокол является частью прекрасного веб-сервисов: они независимы от языка и поэтому совместимы между различными платформами и системами. При документировании REST API не имеет значения, строят ли инженеры API с помощью Java, Ruby, Python или какого-либо другого языка. Запросы выполняются через HTTP, и ответы возвращаются через HTTP.

Диаграмма ниже показывает общую модель REST API:

diagram

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

Любой язык программирования, создающий запрос, будет по-своему отправлять веб-запрос и анализировать ответ на своем языке. Эти специфичные для языка функции отправки запросов и анализа ответов не являются частью REST API (хотя они могут быть предоставлены в прилагаемом SDK). REST API не зависит от языка и обрабатывает входящую и исходящую информацию по HTTP.

API-интерфейсы SOAP являются предшественниками REST API

До того, как REST стал самым популярным веб-сервисом, SOAP (Simple Object Access Protocol) был гораздо более распространенным. Чтобы лучше понять REST, полезно иметь некоторое понимание SOAP. Заодно и увидеть, что отличает SOAP и REST.

SOAP — это стандартизированный протокол, который требует XML в качестве формата сообщений для запросов и ответов. Как стандартный протокол, формат сообщения обычно определяется с помощью файла WSDL (язык описания веб-служб).

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

Сообщения SOAP заключены в «конверт», который включает в себя заголовок и тело, используя определенную схему XML и пространство имен. Пример формата запроса и ответа SOAP см. SOAP против REST 101: понимание различий.

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

SOAP по-прежнему используется в enterprise приложениях (особенно в финансовых учреждениях) со связью server-to-server, но в последние годы SOAP вымещается REST, особенно для API открытых сетей.

REST — стиль, а не стандарт

Как и SOAP, REST (Representational State Transfer) использует HTTP в качестве протокола передачи данных для запросов и ответов. Однако, в отличие от SOAP, REST является архитектурным стилем, а не стандартным протоколом. Вот почему REST API иногда называют RESTful API — REST — это общий стиль, которому следует API.

API-интерфейс RESTful может не соответствовать всем официальным характеристикам REST, указанным доктором Роем Филдингом, который впервые описал эту модель. Следовательно, API являются «RESTful» или «REST-подобными». (Некоторые разработчики настаивают на использовании термина «RESTful», когда API не соответствует всем характеристикам REST, но большинство людей просто называют их «REST API»)

В архитектурном стиле нет ограничений XML в качестве формата сообщения. API REST могут использовать любой формат сообщений, который хотят использовать разработчики API, включая XML, JSON, Atom, RSS, CSV, HTML и другие.

Несмотря на разнообразие параметров формата сообщений, большинство API REST используют JSON (нотацию объектов JavaScript) в качестве формата сообщений по умолчанию. Они используют JSON, потому что он обеспечивает легкий, простой и более гибкий формат сообщений, который увеличивает скорость связи. Облегченная природа JSON также позволяет выполнять сценарии мобильной разработки и легок для парсинга в Интернете с помощью JavaScript.

Напротив, в XML, XSLT больше используется для представления или, скорее, «преобразования» («T» в XSLT) содержимого, хранящегося на языке XML. XSLT обеспечивает удобочитаемость (а не обработку данных, хранящихся в формате XML).

REST фокусируется на ресурсах, доступ к которым осуществляется через URL

Другой отличительной чертой REST является то, что API-интерфейсы REST фокусируются на ресурсах (то есть вещах, а не действиях) и способах доступа к ресурсам. Ресурсы, как правило, являются разными типами информации. Вы получаете доступ к ресурсам через URL (Uniform Resource Locators), так же как переход к URL-адресу в вашем браузере позволяет подключиться к информационному ресурсу. URL-адреса сопровождаются методом, который указывает, как вы хотите взаимодействовать с ресурсом.

Общие методы включают GET (чтение), POST (создание), PUT (обновление) и DELETE (удаление). Конечная точка обычно включает параметры запроса, которые определяют более подробную информацию о представлении ресурса, который нужно увидеть. Например, можно указать (в параметре запроса) ограничение на отображение 5 экземпляров ресурса.

Вот пример, как выглядит конечная точка:

http://apiserver.com/homes?limit=5&format=json

Конечная точка показывает весь путь к ресурсу. Однако в документации вы обычно разделяете этот URL на более конкретные части:

Базовый путь (базовый URL или хост) относится к общему пути для API. В приведенном выше примере базовый путь — http://apiserver.com;
Отношение конечной точки к конечному пути этой точки. В приведенном примере это /homes ;
?limit=5&format=json часть конечной точки содержит параметры строки запроса для этой точки.

В приведенном выше примере конечная точка получит ресурс «homes» и ограничит результат до 5 домов. Будет возвращен ответ в формате JSON.

Можно иметь несколько конечных точек, которые ссылаются на один и тот же ресурс. Вот один из вариантов:

http://apiserver.com/homes/

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

Tip: Отношения между ресурсами и методами часто описывается в терминах «существительные» и «глаголы». Ресурс — это существительное, потому что это объект или вещь. Глагол — это то, что вы делаете с этим существительным. Объединяя существительные с глаголами, вы формируете язык REST.

Более подробно рассмотрим конечные точки в следующих разделах (например, в Обзоре руководства описания API мы рассмотрим каждое свойство ресурса). А здесь дан краткий обзор.

Сама сеть следует за REST

Термины «запросы GET» и «ответы на сообщения», передаваемые по «протоколу HTTP», могут показаться незнакомыми, но это всего лишь официальная терминология REST для описания происходящего. Поскольку мы используем Интернет, мы уже знакомы с тем, как работают API-интерфейсы REST — сама сеть по сути следует стилю RESTful.

Когда мы открываем браузер и переходим на https://idratherbewriting.com, в действительности мы используем протокол HTTP ( http: // ) для отправки запроса GET на ресурс, доступный на веб-сервере. Ответ от сервера отправляет контент с этого ресурса обратно по протоколу HTTP. Наш браузер — это просто клиент, который делает ответ на сообщение читаемым и знакомым нашему глазу.

REST

Можно увидеть этот ответ в curl, если открыть окно терминала и набрать curl https://idratherbewriting.com. (Предполагается, что curl установлен )

Сам Интернет является примером архитектуры стиля RESTful, а значит и то, как работают API REST, скорее всего, станет понятным тем, кто проходит этот курс.

API REST не сохраняют состояния запроса, но ответы могут кэшироваться

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

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

Кэширование API REST аналогично кешированию веб-страниц. Браузер использует значение времени последнего изменения в заголовках HTTP, чтобы определить, нужно ли ему снова получать ресурс. Если содержимое не было изменено с момента последнего извлечения, вместо него можно использовать кэшированную копию. Кэширование увеличивает скорость ответа.

API REST имеют и другие характеристики, о которых можно узнать побольше в этом видео. Одна из таких характеристик включает ссылки в ответах, позволяющие пользователям переходить к дополнительным элементам. Эта функция называется HATEOS, или Hypermedia As The Engine of State.

Изучение подробной теории REST не является целью курса, также, как и незнание подробной теории не станет проблемой документирования REST API. Тем не менее, существует множество технических книг, курсов и веб-сайтов, в которых более подробно рассматриваются концепции, ограничения и архитектура REST API, к которым при желании можно обращаться. Например, посмотрите «Основы программирования: веб-сервисы» Дэвида Гасснера на lynda.com.

API REST не используют файлы WSDL, но некоторые спецификации все же существуют

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

Хотя и существует возможный файл WADL (Web Application Description Language), который можно использовать для описания API-интерфейсов REST, им используются редко, поскольку там неадекватно описываются все ресурсы, параметры, форматы сообщений и другие атрибуты API-интерфейса REST. , (Помните, что REST API — это архитектурный стиль, а не стандартизированный протокол.)

Чтобы понять, как взаимодействовать с REST API, нужно прочитать документацию по API. Необходимость читать документы делает роль технического писателя чрезвычайно важной для документирования API.

Некоторые формальные спецификации — например, OpenAPI и RAML — были разработаны для описания API REST. Когда вы описываете свой API с использованием спецификации OpenAPI или RAML, инструменты, которые могут читать эти спецификации (например, Swagger UI или консоль RAML API), будут генерировать вывод интерактивной документации.

Спецификация OpenAPI может заменить файл WSDL, более распространенный в SOAP. Такие инструменты, как Swagger UI, которые читают документы спецификаций, обычно создают интерактивную документацию (с использованием API-консолей или API-проводников) и позволяют вам тестировать вызовы REST и просматривать ответы прямо в браузере.

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

В целом, API REST более разнообразны и гибки, чем API SOAP, и почти всегда нужно читать документацию, чтобы понять, как взаимодействовать с API REST. Изучая API-интерфейсы REST, можно обнаружить, что они значительно отличаются друг от друга (особенно формат и отображение сайтов документации, которые мы рассмотрим в обзоре сайтов документации API), но все они имеют общие принципы и паттерны. В основе любого REST API лежит запрос и ответ, передаваемые через Интернет.

Методы HTTP запроса

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

Метод GET запрашивает представление ресурса. Запросы с использованием этого метода могут только извлекать данные.

HEAD запрашивает ресурс так же, как и метод GET, но без тела ответа.

POST используется для отправки сущностей к определённому ресурсу. Часто вызывает изменение состояния или какие-то побочные эффекты на сервере.

PUT заменяет все текущие представления ресурса данными запроса.

DELETE удаляет указанный ресурс.

CONNECT устанавливает «туннель» к серверу, определённому по ресурсу.

OPTIONS используется для описания параметров соединения с ресурсом.

TRACE выполняет вызов возвращаемого тестового сообщения с ресурса.

PATCH используется для частичного изменения ресурса.

Спецификации

Спецификация	Название	Комментарий
RFC 7231, секция 4: Request methods	Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content	Определение GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE.
RFC 5789, секция 2: Patch method	PATCH метод для HTTP	Определение PATCH.

Совместимость с браузерами

BCD tables only load in the browser

Смотрите также

Found a content problem with this page?

Edit the page on GitHub.
Report the content issue.
View the source on GitHub.

This page was last modified on 7 авг. 2023 г. by MDN contributors.

Your blueprint for a better internet.

MDN

Support

Product help
Report an issue

Our communities

Developers

Web Technologies
Learn Web Development
MDN Plus
Hacks Blog

Website Privacy Notice
Cookies
Legal
Community Participation Guidelines

Visit Mozilla Corporation’s not-for-profit parent, the Mozilla Foundation.
Portions of this content are ©1998– 2023 by individual mozilla.org contributors. Content available under a Creative Commons license.

В чем отличие REST API от HTTP?

Я так понял, что REST API предоставляет возможность взаимодействия на уровне методов HTTP , отправлять на сервер GET, POST, PATCH, PUT . запросы. Но в чем тогда косвенное отличие? Правильно ли я понимаю, что REST API — это мы просто взяли весь протокол HTTP для работы как базовую точку отсчета и поверх просто накинули пару архитектурных принципов как должны быть выстроены ссылки куда отправляться будут эти HTTP запросы?

Отслеживать
задан 12 мар в 13:18
Anonymous Wizard Anonymous Wizard
115 7 7 бронзовых знаков

HTTP это транспорт, REST это архитектура для API. Что у них общего? Ничего. Это как сравнивать тёплое и мягкое. REST пришел на замену SOAP, вот там отличия и ищите.

12 мар в 13:23
@aepot спасибо за ответ, то есть мое представление в конце вопроса правильное?
12 мар в 13:41

Сложно сказать, есть ли у вас понимание вообще, но в целом вы ничего в конце вопроса противоестественного не написали.

12 мар в 14:45

вопрос примерно аналогичен вопросу: чем отличается тепловоз от ж/д-колеи? (ответ: ну, по колее может ехать тепловоз, а может трамвай, а может электричка, а может вагонетка).

14 мар в 13:04

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

как специалист по АПИ могу честно сказать что RESTом просто называют почти любое АПИ поверх HTTP как противовес SOAP, XML-RPC и JSON-RPC.

Исторически когда зарождался веб начали делать XML-RPC где есть один АПИ в который слали через POST команду в виде XML которая содержала имя метода\функции и параметры к ней. У WordPress кстати ещё вроже сохранился XML-RPC АПИ через который можно создавать статьи. Можешь глянуть чтобы понять.

Потом корпораты добавили XML схему WSDL для описания функций и параметров и так появился SOAP. Его прикол был в том что имея WSDL файл ты мог сгенерировать готовый клиент например на Java это был Axis. Но сам по себе этот стандарт получился просто запредельно раздутый и сложный. При этом всё равно все имплементировали его криво и постоянно куча проблем было. Чисто для примера если у тебя есть поле с датой то оно может форматироваться разными способами. Сам же XML это очень сомнительный формат в котором например просто словаоь ключ:значение (map) передать нельзя и нужно делеать хитрую схемму. Вообщем при слове SOAP у всех бывалых в глазах появляется страх и боль. Тем не менее в банках и прочих «энтерпрайзах» до сих пор его используют.

Потом начали появлятся мобильные приложения и всякие Веб 2.0 сайты с AJAX. И для них нужно было что-то проще. Начали использовать JSON как формат сериализации вместо XML и просто слать POST запросы на сервер но уже не на единый АПИ эндпоинт а куда будет проще. Почти все запросы были простыми CRUD: создать, получить, изменить да и удалить.

И тут Филдинг, один из создателей HTTP, выкатил предложение: а давайте будет переиспользовать HTTP методы и для создания использовать POST, для изменения PUT а для удаления DELETE. При этом будет достаточно только урла и не нужно слать команду в теле запроса. Ну и это всем зашло потому что в теории выглядит очень гармонично. Но на практике же это адищще поскольку удаление почти никогда не надо делать а нужно просто помечать галочкой что удалено. Обновление иногда нужно делать хитрее, например менять пароль у пользователя это отдельная команда.

Тут нужно сделать важную оговорку: броузер сам никогда не шлёт PUT и DELETE. Только форма может засабмитить POST ну или даже GET.

Откуда тогда они взялись в HTTP спеке? А очень просто: изначально веб сделали в ЦЕРНе для просмотра документации не скачивая её всю. И в первом броузере даже можно было любую страницу редактировать и отсылать на сервер через PUT. Но это быстро убрали и вместо этого задумали сделать полноценное расширение WebDAV для того чтобы несколько пользователей могли работать над одним документом и там сохранялась версия изменений. И вот пока делали вебдав решили часть его методов OPTIONS, DELETE, PUT впихнуть в основной HTTP стандарт. Но вообще там ещё больше методов всяких разных, например MKCOL для создания папки. Хорошо что про них никто не знает. А ещё лучше что люди не знают про UPnP где тоже есть свои методы типа NOTIFY.

Тут есть тонкий прикол: по факту АПИ твоего приложения «унаследует» HTTP а значит ты должен переиспользовать HTTP коды ошибок. И если пытешьс редактировать пользователя которого нет то нужно возвращать 404 ошибку. Прикол в том если например ты просто неправильно сконфигурил адрес АПИ то ты всегда будешь получать 404 от самого вебсервера а не от твоего приложения. И это отдельная боль.

Поэтому правильно будет не наследовать а делегировать и всегда отвечать с 200 OK но в случае ошибки передавать её в теле ответа завёрнутую в JSON.

Потом спираль истории сделала новый виток и программистам понадобилось делать схемы апи и генерить клиенты как уже было с SOAP. Тогда придумали Swagger\OpenAPI который по сути тот же WSDL только уже на JSON. И есть всякие там свагер генераторы которые тоже генерят клиенты с багами и несовместимые друг с другом.

Чуть позже намучившись с Рестом программисты взяли всё лучшее и отбросили то что не очень-то и надо типа схемы и придумали простой рабоче-крестьянский JSON-RPC. Это почти идеально для 95% нужд. Единственное что очень топорно файлы через него гонять ведь их нужно кодировать в base64 и запихивать в JSON поле. Если ты новичёк то бери его.

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

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

Под конец добавлю что почти всегда в системе у тебя не просто запрос-ответ но ещё и события и подписка на них. Поэтому рано или поздно любой АПИ эволюционирует и начинает использовать постоянное подключение через WebSocket и модель событие-обработчик. Но это уже другая история.

Типы HTTP-запросов и философия REST

Этот пост — ответ на вопрос, заданный в комментарии к одной из моих статей.

В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.

HTTP

Итак, что же представляет из себя один из основных протоколов интернета? Педантов отправлю к RFC2616, а остальным расскажу по-человечески 🙂

Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.

Стартовые строки для запроса и ответа имеют различный формат — нам интересна только стартовая строка запроса, которая выглядит так:

где METHOD — это как раз метод HTTP-запроса, URI — идентификатор ресурса, VERSION — версия протокола (на данный момент актуальна версия 1.1).

Заголовки — это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.

Тело сообщения — это, собственно, передаваемые данные. В ответе передаваемыми данными, как правило, является html-страница, которую запросил браузер, а в запросе, например, в теле сообщения передается содержимое файлов, загружаемых на сервер. Но как правило, тело сообщения в запросе вообще отсутствует.

Пример HTTP-взаимодействия

GET /index.php HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text/html Connection: close

Первая строка — это строка запроса, остальные — заголовки; тело сообщения отсутствует

HTTP/1.0 200 OK Server: nginx/0.6.31 Content-Language: ru Content-Type: text/html; charset=utf-8 Content-Length: 1234 Connection: close . САМА HTML-СТРАНИЦА .

Ресурсы и методы

Вернемся к стартовой строке запроса и вспомним, что в ней присутствует такой параметр, как URI. Это расшифровывается, как Uniform Resource Identifier — единообразный идентификатор ресурса. Ресурс — это, как правило, файл на сервере (пример URI в данном случае ‘/styles.css’), но вообще ресурсом может являться и какой-либо абстрактный объект (‘/blogs/webdev/’ — указывает на блок «Веб-разработка», а не на конкретный файл).

Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно — получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».

GET — получение ресурса
POST — создание ресурса
PUT — обновление ресурса
DELETE — удаление ресурса

В игру вступает REST

REST (REpresentational State Transfer) — это термин был введен в 2000-м году Роем Филдингом (Roy Fielding) — одним из разработчиков протокола HTTP — в качестве названия группы принципов построения веб-приложений. Вообще REST охватывает более широкую область, нежели HTTP — его можно применять и в других сетях с другими протоколами. REST описывает принципы взаимодействия клиента и сервера, основанные на понятиях «ресурса» и «глагола» (можно понимать их как подлежащее и сказуемое). В случае HTTP ресурс определяется своим URI, а глагол — это HTTP-метод.

REST предлагает отказаться от использования одинаковых URI для разных ресурсов (то есть адреса двух разных статей вроде /index.php?article_id=10 и /index.php?article_id=20 — это не REST-way) и использовать разные HTTP-методы для разных действий. То есть веб-приложение, написанное с использованием REST подхода будет удалять ресурс при обращении к нему с HTTP-методом DELETE (разумеется, это не значит, что надо давать возможность удалить всё и вся, но любой запрос на удаление в приложении должен использовать HTTP-метод DELETE).

REST дает программистам возможность писать стандартизованные и чуть более красивые веб-приложения, чем раньше. Используя REST, URI для добавления нового юзера будет не /user.php?action=create (метод GET/POST), а просто /user.php (метод строго POST).

В итоге, совместив имеющуюся спецификацию HTTP и REST-подход наконец-то обретают смысл различные HTTP-методы. GET — возвращает ресурс, POST — создает новый, PUT — обновляет существующий, DELETE — удаляет.

Проблемы?

Да, есть небольшая проблема с применением REST на практике. Проблема эта называется HTML.

PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос.

Дело в том, спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно. Например, в Rack (механизм, на базе которого Ruby взаимодействует с веб-сервером; с применением Rack сделаны Rails, Merb и другие Ruby-фреймворки) в форму можно добавить hidden-поле с именем «_method», а в качестве значения указать название метода (например, «PUT») — в этом случае будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.