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

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

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

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

еще одна архитектура restraint REST не должна использовать контекст сеанса при общении с клиентом (без состояния), что означает все информация должна понимать, кто является клиентом и что он хочет, передается вместе с веб-сообщением. каждый вызов функции является самостоятельной описательный, нет никакого предварительного разговора с клиентом, который может быть выполнена ссылка в сообщении. поэтому клиент не может сказать вам "дайте мне следующую страницу", так как у вас нет сеанса для хранения предыдущей страницы и какой страницы вы хотите, клиент должен будет сказать:"Меня зовут Юваль, получите мне страницу 2 определенного сообщения на определенном форуме". это означает, что немного больше данных придется передавать в сообщении, но подумайте о разнице между поиском ошибки, сообщенной из функции "get me next page" в противоположность "get me page 2 of question id 2190836 in Stack overflow".

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

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

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

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

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

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

Не совсем...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

характеристики:

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

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

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

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

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

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

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

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

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

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

руководитель:

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

варианты:

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

HTTP-ответы

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

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

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

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

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

REST API должен управляться гипертекстом

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

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

• API REST не должен зависеть от какого-либо одного протокола связи, хотя его успешное сопоставление с данным протоколом может зависеть от наличие метаданных, выбор методов и т. д. Как правило, любой элемент протокола, использующий URI для идентификации, должен позволять использовать любую схему URI для этой идентификации. [Неудача здесь подразумевает, что идентификация неотделима от взаимодействия.]
• API REST не должен содержать каких-либо изменений в протоколах связи, кроме заполнения или фиксации сведений о недооцененных битах стандартных протоколов, таких как метод исправления HTTP или Заголовок ссылки поле. Обходные пути для сломанных реализаций (таких как те браузеры, которые достаточно глупы, чтобы полагать, что HTML определяет набор методов HTTP) должны быть определены отдельно или, по крайней мере, в приложениях, с ожиданием, что обходной путь в конечном итоге будет устаревшим. [Сбой здесь означает, что интерфейсы ресурсов являются объектно-специфичными, а не универсальными.]
• API REST должен потратить почти все свои описательные усилия на определение типов носителей, используемых для представления ресурсов и управления состояние приложения или при определении расширенных имен отношений и / или гипертекстовой разметки для существующих стандартных типов носителей. Любые усилия, потраченные на описание методов использования интересующих URI, должны быть полностью определены в рамках правил обработки для типа носителя (и, в большинстве случаев, уже определены существующими типами носителей). [Неудача здесь подразумевает, что внеполосная информация управляет взаимодействием, а не гипертекстом.]
• API REST не должен определять фиксированный имена ресурсов или иерархии (очевидная связь клиента и сервера). Серверы должны иметь свободу управления собственным пространством имен. Вместо этого позвольте серверам инструктировать клиентов о том, как создавать соответствующие URI, например, в HTML-формах и шаблонах URI, определяя эти инструкции в типах носителей и связях ссылок. [Сбой здесь означает, что клиенты принимают структуру ресурсов из-за внеполосной информации, такой как доменный стандарт, который является ориентированный на данные эквивалент функциональной связи RPC].
• API REST никогда не должен иметь "типизированных" ресурсов, важных для клиента. Авторы спецификаций могут использовать типы ресурсов для описания реализации сервера за интерфейсом, но эти типы должны быть неуместны и невидимы для клиента. Единственными типами, значимыми для клиента, являются тип носителя текущего представления и стандартизированные имена отношений. [Кабуто]
• API REST должен вводится без предварительного знания, кроме начального URI (закладки) и набора стандартных типов носителей, которые подходят для целевой аудитории (т. е., как ожидается, будут поняты любым клиентом, который может использовать API). С этого момента все переходы состояния приложения должны определяться выбором клиентом предоставленных сервером вариантов, которые присутствуют в полученных представлениях или подразумеваются манипуляцией пользователя этими представлениями. Переходы могут быть определены (или ограничены by) знание клиентом типов носителей и механизмов коммуникации ресурсов, которые могут быть улучшены на лету (например, код по требованию). [Неудача здесь подразумевает, что внеполосная информация управляет взаимодействием, а не гипертекстом.]

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