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

Question

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

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

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

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

Answer 1

С Вы не знаете разницу между HTTP и REST

Таким образом, архитектура REST и протокол HTTP 1.1 независимы от каждого другой, но протокол HTTP 1.1 был создан, чтобы быть идеальным протоколом для следовать принципам и ограничениям ОТДЫХА. Один из способов посмотреть на связь между HTTP и REST заключается в том, что REST является проектом, и HTTP 1.1 является реализацией этого дизайна.

Answer 2

HTTP is a contract, a communication protocol and REST is a concept, an architectural style, который может использовать HTTP, FTP или другие протоколы связи, но широко используется с HTTP.

REST implies a series of constraints about how Server and Client should interact.HTTP is a communication protocol with a given mechanism for server-client data transfer, он чаще всего используется в REST API только потому, что REST was inspired by WWW (world wide web) which largely used HTTP до определения REST, поэтому проще реализовать стиль REST API с HTTP.

There are three major constraints in REST (but there are more):

1. Взаимодействие между сервером и клиентом должнобыть описанным только через гипертекст.

2. Сервер и клиент должны быть слабо связаны и не делать предположений друг о друге.Клиент должен знать только точку входа в ресурс.Данные взаимодействия должны быть предоставлены сервером в ответе.

3. Сервер не должен хранить никакой информации о контексте запроса.Запросы должны быть независимыми и идемпотентными (то есть, если один и тот же запрос повторяется бесконечно, получается тот же самый результат)

И HTTP - это просто протокол связи (инструмент), который может помочь в достижении этого.

Для получения дополнительной информации проверьте эти ссылки:

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Answer 3

API-интерфейсы REST должны работать с гипертекстом

Из блога Роя Филдинга вот несколько способов проверить, создаете ли вы HTTP API или REST API:

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

• API REST не должен зависеть от какого-либо одного протокола связи, хотя его успешное отображение на данный протокол может зависеть от доступности метаданных, выбора методов и т. Д. В общем, любой элемент протокола, который использует URI для идентификация должна позволять использовать любую схему URI для этой идентификации. [Ошибка здесь означает, что идентификация не отделена от взаимодействия.]
• REST API не должен содержать каких-либо изменений в протоколах связи, за исключением заполнения или исправления деталей недостаточно определенных битов стандартных протоколов, таких как метод PATCH HTTP или поле заголовка Link. Обходные пути для неработающих реализаций (например, таких браузеров, которые достаточно глупы, чтобы полагать, что HTML определяет набор методов HTTP) должны определяться отдельно или, по крайней мере, в приложениях, с ожиданием того, что обходной путь в конечном итоге устареет. [Ошибка здесь подразумевает, что интерфейсы ресурса являются объектно-ориентированными, а не универсальными.]
• API-интерфейс REST должен потратить почти все свои описательные усилия на определение типов носителей, используемых для представления ресурсов и управления состоянием приложения, или на определение расширенных имен отношений и / или разметки с поддержкой гипертекста для существующих стандартных носителей. типы. Любое усилие, затрачиваемое на описание того, какие методы использовать с какими интересующими URI, должно быть полностью определено в рамках правил обработки для типа носителя (и, в большинстве случаев, уже определено существующими типами носителя). [Ошибка здесь подразумевает, что внешняя информация является движущей силой взаимодействия, а не гипертекста.]
• REST API не должен определять фиксированные имена ресурсов или иерархии (очевидная связь клиента и сервера). Серверы должны иметь свободу управления своим собственным пространством имен. Вместо этого позвольте серверам инструктировать клиентов о том, как создавать соответствующие URI, например, в HTML-формах и шаблонах URI, определяя эти инструкции в типах мультимедиа и ссылочных отношениях. [Ошибка здесь подразумевает, что клиенты принимают структуру ресурса из-за внеполосной информации, такой как специфичный для области стандарт, который является ориентированным на данные эквивалентом функциональной связи RPC].
• REST API никогда не должен иметь «типизированных» ресурсов, значимых для клиента. Авторы спецификаций могут использовать типы ресурсов для описания реализации сервера за интерфейсом, но эти типы должны быть неактуальными и невидимыми для клиента. Единственными типами, которые важны для клиента, являются тип медиа текущего представления и стандартизированные имена отношений. [Ditto] * +1021 *
• API REST следует вводить без каких-либо предварительных знаний, кроме начального URI (закладки) и набора стандартизированных типов мультимедиа, подходящих для предполагаемой аудитории (то есть ожидается, что это поймет любой клиент, который может использовать API). С этого момента все переходы состояния приложения должны определяться выбором клиентом предоставленных сервером вариантов, которые присутствуют в полученных представлениях или подразумеваются пользовательскими манипуляциями с этими представлениями. Переходы могут быть определены (или ограничены) знаниями клиента о типах мультимедиа и механизмах обмена ресурсами, которые могут быть улучшены на лету (например, код по запросу). [Ошибка здесь подразумевает, что внешняя информация является движущей силой взаимодействия, а не гипертекста.]