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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

Не совсем...

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

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

Ответ 9

REST - только HTTP. HTTP наиболее широко используется, и когда мы говорим о веб-сервисах REST, мы просто принимаем HTTP. HTTP определяет интерфейс со своими методами (GET, POST, PUT, DELETE, PATCH и т.д.) И различными заголовками, которые могут использоваться единообразно для взаимодействия с ресурсами. Эта равномерность может быть достигнута и с другими протоколами.

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

Ответ 10

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

Ответ 11

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОЛОВА:

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

OPTIONS:

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

HTTP-ответы

Перейдите сюда для всех ответов.

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

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

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

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

Ответ 12

HTTP означает протокол передачи HyperText и способ передачи файлов. Этот протокол используется для связывания страниц гипертекста в том, что мы называем всемирной сетью. Тем не менее, есть другие доступные протоколы передачи, такие как FTP и gopher, но они менее популярны.

REpresentational State Transfer или REST представляет собой набор ограничений, которые обеспечивают масштабируемую, отказоустойчивую и легко расширяемую систему. Всемирная паутина - пример такой системы (и самый большой пример, можно сказать). REST сам по себе не является новым изобретением, но это документация на таких системах, как всемирная сеть.

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