В чем разница между HTTP и REST?

Question

Много прочитав о различиях между REST и SOAP, у меня сложилось впечатление, что REST - это просто другое слово для HTTP. Может кто-нибудь объяснить, какую функциональность REST добавляет в HTTP?

Примечание : я не ищу сравнения REST и SOAP.

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

Примечание : Теперь я понимаю значение REST; как замечает Эмиль Иванов , REST означает использование HTTP таким, каким оно должно быть. Тем не менее, я не уверен, заслуживает ли это своего собственного термина, и, конечно же, я не получаю ажиотажа вокруг него.

Answer 1

Нет, REST - это способ HTTP должен использоваться .

Сегодня мы используем лишь небольшую часть методов протокола HTTP, а именно GET и POST.REST-способ сделать это - использовать все методы протокола.

Например, REST диктует использование DELETE для удаления документа (будь то файл, состояние и т. Д.) За URIтогда как в случае HTTP вы могли бы неправильно использовать запрос GET или POST, например ...product/?delete_id=22.

Answer 2

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

REST означает, что основной концепцией, которую вы используете при разработке приложения, является ресурс: для каждого действия, которое вы хотите выполнить, вам нужно определить ресурс, на котором вы обычно выполняете только операцию CRUD, что является простой задачей. для этого очень удобно использовать 4 глагола, используемые в протоколе HTTP, против 4 операций CRUD (Get for Read, POST для CREATE, PUT для UPDATE и DELETE для DELETE). это отличается от более старой концепции RPC (удаленного вызова процедур), в которой у вас есть набор действий, которые вы хотите выполнить в результате вызова пользователя. если вы думаете, например, о том, как описать facebook как в сообщении, с помощью RPC вы можете создать службы с именами AddLikeToPost и RemoveLikeFromPost и управлять ими вместе со всеми другими службами, связанными с сообщениями FB, поэтому вам не нужно создавать специальные объект для лайка. с REST у вас будет объект Like, которым будут управлять отдельно функции Delete и Create. Это также означает, что он будет описывать отдельную сущность в вашей базе данных. это может показаться небольшой разницей, но такая работа обычно приводит к гораздо более простому коду и гораздо более простому приложению. при таком дизайне большая часть логики приложения очевидна из структуры (модели) объекта, в отличие от RPC, с которой вам обычно приходится явно добавлять гораздо больше логики.

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

Еще одна существующая архитектура REST-ограничения - не использовать контекст сеанса при взаимодействии с клиентом (без сохранения состояния), а это означает, что вся информация должна понимать, кто является клиентом и что он хочет, передается с веб-сообщением. каждый вызов функции является информативным, нет предыдущего разговора с клиентом, на который можно сослаться в сообщении. поэтому клиент не может сказать вам «дайте мне следующую страницу», так как у вас нет сеанса для сохранения предыдущей страницы и какой страницы вы хотите, клиент должен будет сказать «меня зовут yuval, получите мне страница 2 конкретного поста в конкретном форуме ". это означает, что в сообщении должно быть передано немного больше данных, но подумайте о разнице между поиском ошибки, сообщенной функцией «get me next page», в противоположность «get me page 2 of id 2190836 с переполнением стека».

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

Answer 3

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

Answer 4

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

Если вы ищете наиболее существенные ограничения REST, которые отличают RESTful-приложение от любого другого HTTP-приложения, я бы сказал, что ограничение «самоописание» и ограничение гипермедиа (иначе гипермедиа как механизм состояния приложения (HATEOAS) )) являются наиболее важными.

Ограничение самоописания требует, чтобы запрос RESTful был полностью информативным в намерениях пользователей. Это позволяет посредникам (прокси и кешам) безопасно воздействовать на сообщение.

Ограничение HATEOAS касается превращения вашего приложения в сеть ссылок, где текущее состояние клиента основано на его месте в этой сети. Это сложная концепция, и для ее объяснения требуется больше времени, чем сейчас.

Answer 5

Не совсем ...

http://en.wikipedia.org/wiki/Representational_State_Transfer

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

http://www.looselycoupled.com/glossary/SOAP

(Простой протокол доступа к объектам) стандарт для сообщений веб-сервисов. На основе XML SOAP определяет конверт формат и различные правила для описывая его содержание. Видел (с WSDL и UDDI) как один из трех основные стандарты веб-сервисов, это предпочтительный протокол для обмен веб-сервисами, но нет означает единственный; Сторонники ОТДЫХА скажи что добавляет ненужного сложность.

Answer 6

Насколько я понимаю, REST обеспечивает использование доступных HTTP-команд в том виде, в каком они должны были использоваться.

Например, я мог бы сделать:

GET
http://example.com?method=delete&item=xxx

Но с остальными я бы использовал метод запроса "DELETE", устраняя необходимость в параметре запроса "method"

DELETE
http://example.com?item=xxx

Answer 7

REST - это особый подход к проектированию больших систем (например, сети).

Это набор «правил» (или «ограничений»).

HTTP - это протокол, который пытается подчиняться этим правилам.

Answer 8

HTTP - это протокол связи, который транспортирует сообщения по сети. SOAP - это протокол для обмена сообщениями на основе XML, который может использовать HTTP для передачи этих сообщений. Rest - это протокол для обмена любыми (XML или JSON) сообщениями, которые могут использовать HTTP для транспортировки этих сообщений.

Answer 9

REST = Передача представительского состояния

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

REST - это протокол для обмена любыми (XML, JSON и т. Д.) Сообщениями, которые могут использовать HTTP для транспортировки этих сообщений.

Особенности:

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

Преимущества безгражданства:

1. Веб-службы могут обрабатывать каждый вызов метода отдельно.
2. Веб-сервисам не нужно поддерживать предыдущее взаимодействие с клиентом.
3. Это, в свою очередь, упрощает дизайн приложения.
4. HTTP, в отличие от TCP, сам по себе является протоколом без сохранения состояния, поэтому веб-службы RESTful без проблем работают с протоколами HTTP.

Недостатки безгражданства:

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

Методы HTTP, поддерживаемые REST:

GET: / string / someotherstring Он идемпотентен и в идеале должен возвращать одни и те же результаты при каждом вызове

PUT: Так же, как GET. Идемпотент и используется для обновления ресурсов.

POST: должен содержать URL и тело Используется для создания ресурсов. Несколько вызовов должны в идеале возвращать разные результаты и создавать несколько продуктов.

DELETE: Используется для удаления ресурсов на сервере.

ГОЛОВА:

Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН возвращать тело сообщения в ответе. Мета-информация, содержащаяся в заголовках HTTP в ответ на запрос HEAD, ДОЛЖНА быть идентична информации, отправленной в ответ на запрос GET.

ВАРИАНТЫ:

Этот метод позволяет клиенту определять параметры и / или требования, связанные с ресурсом или возможностями сервера, не предполагая действия ресурса или не инициируя извлечение ресурса.

HTTP-ответы

Здесь вы найдете ответы на все вопросы .

Вот несколько важных: 200 - ОК 3XX - требуется дополнительная информация от клиента и перенаправление URL 400 - Неверный запрос
401 - Несанкционированный доступ
403 - Запрещено
Запрос был действителен, но сервер отказывается от действия. Пользователь может не иметь необходимых разрешений для ресурса или ему может потребоваться какая-либо учетная запись.

404 - Не найдено
Запрашиваемый ресурс не найден, но может быть доступен в будущем. Последующие запросы клиента допустимы.

405 - метод не разрешен Метод запроса не поддерживается для запрошенного ресурса; например, запрос GET для формы, которая требует представления данных через POST, или запрос PUT для ресурса, доступного только для чтения.

404 - Запрос не найден
500 - Внутренняя ошибка сервера
502 - ошибка неверного шлюза

Answer 10

REST не обязательно привязан к HTTP .Веб-сервисы RESTful - это просто веб-сервисы, которые следуют архитектуре RESTful.

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface