Введение в REST

REST или Передача репрезентативного состояния — это архитектурный стиль или, проще говоря, набор ограничений.

Мы рассмотрим ограничения, налагаемые REST для веб-приложений, но некоторые основные моменты:

• Унифицированные интерфейсы: все ресурсы идентифицируются URI (думаю: ссылки)
• Он основан на кешируемом коммуникационном протоколе клиент-сервер без сохранения состояния (например, HTTP).
• Взаимодействие с ресурсами осуществляется с помощью набора стандартных методов (например, HTTP-глаголы).

REST можно рассматривать как легкую альтернативу таким механизмам, как RPC (удаленные вызовы процедур) и протоколы веб-служб (SOAP, WSDL и т. Д.), Но это гораздо больше, чем это! Не будет преувеличением сказать, что REST использовался для руководства проектированием и разработкой архитектуры для современного Интернета.

Термин REST был определен в 2000 году Роем Филдингом в его докторской диссертации в Калифорнийском университете в Ирвине.

• Фон
• Что такое ОТДЫХ?
• HTTP
• HATEAOS
• Резюме
• терминология
• Источники, ссылки, библиография

Фон

Краткая история WWW

Еще в 1989 году Тим Бернерс-Ли впервые предложил проект «WorldWideWeb». Бернерс-Ли работал инженером-программистом в CERN, лаборатории физики крупных частиц в Швейцарии. Многие ученые работали в ЦЕРН в течение некоторого времени, а затем вернулись в свои собственные лаборатории по всему миру, и поэтому им была необходима возможность поделиться и связать свои исследовательские документы. Чтобы облегчить это, Бернерс-Ли предложил три технологии, которые станут основой Интернета:

• HTTP: протокол передачи гипертекста. HTTP — это протокол или формальный набор правил для обмена информацией через Интернет. Это позволяет для поиска связанных ресурсов со всей сети.
• HTML: язык разметки гипертекста. Формат публикации для Интернета, включая возможность форматирования документов и ссылки на другие документы и ресурсы.
• URI: унифицированный идентификатор ресурса. Это своего рода «адрес», который уникален для каждого ресурса в Интернете.

(мы не собираемся углубляться в HTML здесь, вместо этого мы сосредоточимся на HTTP и немного на URI)

HTTP 1.0

Первая документированная версия HTTP была HTTP V0.9 (1991) и имела только один метод, а именно GET, который отправлял запрос серверу, а сервер отвечал HTML-страницей. Это было хорошее начало, но нужно много улучшений, чтобы поддержать растущую популярность Интернета.

Итак, Бернерс-Ли объединился с исследователем Роем Филдингом и другими для разработки HTTP 1.0 . HTTP 1.0 преобразовал HTTP из простого приложения запроса / ответа в настоящий протокол обмена сообщениями. Он описал полный формат сообщения для HTTP и объяснил, как его следует использовать для клиентских запросов и ответов сервера, а также поддерживал несколько типов мультимедиа.

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

HTTP 1.1

Перейти к 1994 году. Сеть росла очень быстро. Это было захватывающее время. WWW становился модным словом и получал огромное количество прессы. Такие сайты, как Hotmail, Yahoo, Altavista взлетели. Google еще даже не существовало.

Но архитектура и технологии, на которых была построена сеть, начинали скрипеть по швам. Итак, TBL, Fielding, которые были исследователями в MIT и UCI соответственно, и ряд других ведущих технологов, включая сотрудников из Compaq, Xerox и Microsoft, собрались вместе, чтобы определить и улучшить инфраструктуру WWW через рабочие группы IETF по URI, HTTP и HTML.

Благодаря этой работе появился HTTP 1.1 .

Некоторые из больших улучшений, представленных в HTTP 1.1:

• Поддержка нескольких имен хостов: позволяет одному веб-серверу обрабатывать запросы для множества разных виртуальных хостов.
• Постоянные соединения: позволяет клиенту отправлять несколько запросов на документы в одном сеансе TCP.
• Частичный выбор ресурса: клиент может запросить только часть ресурса, а не весь документ, что снижает нагрузку и необходимую пропускную способность
• Лучшая поддержка кеширования и прокси
• Согласование содержимого: позволяет клиенту и серверу обмениваться информацией, чтобы помочь выбрать лучший ресурс, когда доступно несколько.
• Лучшая безопасность: определяет методы аутентификации и, как правило, более «осведомлен о безопасности»

Работа над HTTP 1.1 началась в 1994 году, и он был официально выпущен в 1997 году.

А какая версия HTTP 1.1 используется сегодня? Еще 1.1, более 25 лет спустя! Учитывая, как быстро меняются технологии, это невероятное достижение. Сколько проектов, над которыми вы работали, так хорошо выдержали испытание временем?

Уроки выучены

Филдинг был вовлечен в Интернет с самого детства и из первых рук пережил его быстрый рост, как в качестве пользователя, так и в качестве архитектора. Он лучше всех понимал причины его успеха, поэтому после выпуска HTTP 1.1 Филдинг начинает писать о том, что он узнал, работая над HTTP и другими веб-технологиями (Филдинг также принимал участие в разработке HTML, URIs и был соучредителем проекта Apache HTTP Server). Он взял знание архитектурных принципов сети и представил их как структуру ограничений, или, как он их назвал, архитектурный стиль. В частности, Филдинг написал кандидатскую диссертацию, посвященную обоснованию и основным архитектурным принципам проектирования современной веб-архитектуры.

Диссертация Филдинга была опубликована в 2000 году и называлась « Архитектурные стили и проектирование сетевых программных архитектур» . Я должен признать, что я не читал много кандидатских диссертаций, но большинство из них являются одними из самых читаемых из них. Он даже содержит цитаты Монти Пайтона!

В нем Филдинг обсуждает сетевые архитектуры приложений и архитектурные стили, прежде чем вводить и определять термин REST. Несмотря на то, что он был представлен в статье Филдинга, Филдинг отметил, что «REST использовался для руководства проектированием и разработкой архитектуры современного Интернета». Таким образом, хотя термин REST появился только после этого, это стиль дизайна HTTP. Филдинг не «изобрел» REST в своей статье, вместо этого он разработал его в сотрудничестве со своими коллегами, работая над HTTP и URI, но именно в его статье был придуман и определен термин.

Филдинг попытался ответить на вопрос, почему Интернет был такой успешной платформой, объяснив ее руководящими принципами, и как их можно правильно применять при построении распределенных систем?

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

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

Что такое ОТДЫХ?

REST — это архитектурный стиль или набор ограничений для распределенных гипермедиа систем.

Ограничения

Представьте, что вы проектировали автостраду. Вы можете налагать правила, например, только на автомобили (без грузовиков, пешеходов или велосипедов), все движение должно двигаться между 40 и 70 милями в час, и не должно быть светофоров (только на пандусах). Хотя эти правила ограничивают систему, они заставляют ее работать лучше в целом; в этом случае пропускать больше трафика быстрее и быстрее.

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

Какие ограничения были предложены Филдингом?

1) Клиентский сервер

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

2) без гражданства

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

3) Кеш

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

4) Единый интерфейс

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

5) Многоуровневая система

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

6) Код по требованию

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

Это ограничения, которые составляют REST. Далее HTTP.

HTTP

HTTP играет особую роль в веб-архитектуре и, в частности, в REST.

Однако обратите внимание, что REST не должен использовать HTTP. Существуют и другие протоколы прикладного уровня, которые, возможно, могут быть кандидатами для использования с REST: Gopher широко использовался в первые дни Интернета, хотя его обгонял HTTP; Сам Филдинг работал над новым http-подобным протоколом под названием waka ; Существует также разработанный Google протокол под названием SPDY , целью которого является снижение задержки загрузки веб-страниц и повышение безопасности веб-страниц.

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

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

Пример запроса

Пример HTTP-запроса:
GET /index.html HTTP / 1.1
Хост: www.example.com

Это состоит из следующих компонентов:

• Метод: ПОЛУЧИТЬ
• URI: /index.html
• Версия: HTTP / 1.1
• Заголовки: Хост: www.example.com
• Тело: пусто в этом случае

Пример ответа

Код версии / статуса; Фраза причины

В приведенном выше примере запроса глаголом является GET. Глаголы HTTP также известны как методы, есть ли 8 поддерживаемых в HTTP 1.1 ( RFC 2616 ). Сначала мы рассмотрим 4 наиболее часто используемых глагола: GET, PUT, DELETE, POST. Затем мы рассмотрим менее используемые: HEAD, OPTIONS, TRACE и CONNECT.

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

Методы HTTP

Безопасные методы

Безопасные методы — это методы, которые не изменяют ресурсы, они используются только для поиска. (Строго говоря, некоторые вещи могут измениться, например, журналы, кэши и т. Д., Но представление рассматриваемого ресурса не должно).
Безопасные методы: HEAD, GET, OPTIONS и TRACE. Напротив, небезопасные методы, такие как POST, PUT, DELETE и PATCH, предназначены для того, чтобы вызывать побочные эффекты на сервере.

Идемпотентные методы

Идемпотентные методы можно вызывать многократно без разных результатов. Назовите его один раз или тысячу раз, результат будет таким же. Например, умножение на 1 является идемпотентной операцией. Так же как и назначение «a = 4;»

Более формально: «Методы могут также обладать свойством идемпотентности в том, что (кроме ошибок, связанных с ошибками или истечением срока), побочные эффекты от N> 0 идентичных запросов такие же, как и для одного запроса». [7]

Методы GET, HEAD, PUT и DELETE разделяют это свойство. Кроме того, методы OPTIONS и TRACE НЕ ДОЛЖНЫ иметь побочных эффектов, и поэтому являются по своей сути идемпотентными.

Общие методы

А теперь взглянем на 4 наиболее часто используемых глагола: GET, PUT, DELETE, POST

ПОЛУЧИТЬ

Получить ресурс, указанный в URI. Самый простой и самый распространенный метод! Тот, который вы используете каждый раз, когда вы получаете доступ к веб-странице.

ПОЛОЖИТЬ

Сохраните предоставленную сущность под предоставленным URI. Если уже существует, обновите (и верните либо 200 OK, либо 204 No Content). Если не создать с этим URI (и вернуть ответ «201 Created»).

ПОЧТА

Запрос принять объект в качестве нового подчиненного ресурса, идентифицируемого URI. Например

• Отправить данные из формы в процесс обработки данных;
• Опубликовать сообщение в списке рассылки или блоге

На простом английском создайте ресурс.

УДАЛИТЬ

Запрашивает, чтобы сервер удалил ресурс, указанный в URI.

PUT vs POST

Хорошо, прежде чем мы перейдем к другим менее используемым глаголам HTTP, давайте взглянем на 2 из часто используемых выше глаголов, которые часто наиболее сбивают с толку: PUT и POST.

Офис HTTP 1.1 Doc (RFC 2616) заявляет:

«Принципиальное различие между запросами POST и PUT отражается в различном значении Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать вложенную сущность. Этот ресурс может быть процессом приема данных, шлюзом к другому протоколу или отдельным объектом, принимающим аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный в запросе — пользовательский агент знает, для чего предназначен URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к какому-либо другому ресурсу ».

Это, однако, немного глоток!

PUT и POST могут использоваться для создания или обновления ресурса, но вот некоторые (иногда противоречивые!) Практические правила:

• PUT для обновления; POST для создания
• PUT идемпотент; POST нет;
• Кто создает URL ресурса?
  • PUT предназначен для создания, когда вы знаете URL-адрес того, что вы создадите;
  • POST предназначен для создания, когда сервер выбирает URL для вас (вы просто знаете URL «фабрики» или менеджера, который создает)

• Существует также недавний аргумент (например, из Thoughtworks), который говорит, что не используйте Put, всегда Post (и вместо этого публикуйте события).

Краткий ответ? Краткого ответа нет! Используйте свое лучшее суждение.

Посмотрите некоторые полезные обсуждения в этой публикации на стеке .

Менее распространенные методы

Остальные 4 менее используемых глагола HTTP: HEAD, OPTIONS, TRACE и CONNECT.

ПАРАМЕТРЫ

Запрос информации о возможностях сервера, например запрос списка методов HTTP, которые могут использоваться на этом ресурсе. Это будет выглядеть примерно так: 200 ОК

Разрешить: HEAD, GET, PUT, DELETE, OPTIONS

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

ГЛАВА

Идентичен GET за исключением того, что сервер НЕ ДОЛЖЕН возвращать тело сообщения в ответе. Используется для получения метаинформации о сущности, подразумеваемой запросом, без передачи самого тела сущности.

Зачем использовать? Полезно для тестирования ссылок, например, на валидность, доступность.

TRACE

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

CONNECT

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

Преобразует соединение запроса в прозрачный туннель TCP / IP , обычно для упрощения связи с шифрованием SSL ( HTTPS ) через незашифрованный HTTP-прокси .

Коды ответа HTTP

См. Http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.

Код	Смысл	Простой английский (с точки зрения пользователя)
1хх	Информационная; указывает на предварительный ответ, например, 100	К вашему сведению, хорошо, и клиент должен продолжить запрос
2xx	успешный	Все хорошо
3xx	Перенаправление	Что-то пошевелилось
4xx	Ошибка клиента	Ты испортил
5xx	Ошибка сервера	Мы испортили

Почему REST и HTTP?

Потому что HTTP обеспечивает все характеристики, необходимые для REST.

1. Клиентский сервер

   Http — это «протокол в вычислительной модели клиент-сервер», поэтому он отвечает первому требованию REST. При использовании HTTP часто клиент является веб-браузером, а сервер — частью программного обеспечения, обслуживающего контент, такой как Apache, IIS или Nginx. Однако с «Интернетом вещей» все становится менее привычным. Клиент может быть вашим тостером!

2. Stateless

   HTTP — это протокол без сохранения состояния. HTTP-серверы не обязаны хранить какую-либо информацию или состояние между запросами.

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

3. кэш

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

4. Единый интерфейс

   Использование интерфейсов для отделения клиента / вызывающего абонента от реализации является распространенной концепцией программного обеспечения.

   • Идентификация ресурсов

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

     Как вы определяете книгу? example.com/books/1234

     Как вы идентифицируете пользователя? example.com/users/sabram

     Все ресурсы идентифицируются единым интерфейсом — URI

   • Манипулирование ресурсами через эти представления

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

   • Информативные сообщения

     В HTTP сообщения могут описывать себя, используя типы мультимедиа (MIME), коды состояния и заголовки, чтобы, например, указать их кешируемость.

   • Гипермедиа как двигатель состояния приложения (AKA HATEOAS)

   Больше позже! См. ниже.

   Единый интерфейс на простом английском языке.

   Хорошо, это покрывает то, что Филдинг должен был сказать в своей диссертации о единообразных интерфейсах, но что все это означает на простом английском языке?

   Ранее я упоминал, что использование интерфейсов для отделения клиента / вызывающей стороны от реализации является распространенной концепцией программного обеспечения. Точно так же, при разработке графических интерфейсов у вас в идеале должен быть очень простой пользовательский интерфейс, но тот, который все еще позволяет пользователю выполнять сложные задачи. Как правило, простой интерфейс, который предоставляет клиенту / пользователю все необходимые им возможности, скрывая при этом основные сложности реализаций, является идеальной целью, но ее трудно достичь. Но это именно то, чего Филдинг достиг с REST. Интерфейс — это просто ссылка (или, точнее, URI)! Что касается самого простого интерфейса, который вы можете придумать.

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

5. Многоуровневая система

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

   HTTP поддерживает наслоение через прокси-серверы и кэширование.

6. Код-On-Demand

   Это на самом деле необязательное ограничение в REST. Например, вы можете запросить ресурс и получить этот ресурс с помощью некоторого JavaScript.

HATEAOS

Клиенты знают несколько простых фиксированных точек входа в приложение, но не имеют никаких знаний о них. Вместо этого они переходят (состояния) с помощью этих ссылок и ссылок, к которым они ведут. Другими словами, переходы состояний управляются клиентом на основе параметров, которые предоставляет сервер.

Если вы думаете о Hypermedia как о просто ссылках, то «Hypermedia как движок состояния приложения» просто использует обнаруженные вами ссылки для навигации (или переходного состояния) через приложение.

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

Процитирую самого Филдинга:

«Передача репрезентативного состояния призвана создать представление о том, как ведет себя хорошо разработанное веб-приложение:

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

Резюме

Что такое ОТДЫХ?

• Красивые URL?
• Альтернатива SOAP или RPC?

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

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

• Унифицированные интерфейсы: все ресурсы идентифицируются по URI
• Методы HTTP: все ресурсы могут быть созданы / доступны / обновлены / удалены стандартными методами HTTP
• Stateless: на сервере нет состояния

терминология

Давайте определим некоторую полезную терминологию, которая имеет отношение к любому обсуждению REST.

Архитектура

Википедия: Архитектура программного обеспечения относится к структурам высокого уровня системы программного обеспечения, дисциплине создания таких структур и документации этих структур. Архитектура системы программного обеспечения — это метафора, аналогичная архитектуре здания.

Филдинг: Архитектура программного обеспечения — это абстракция элементов времени выполнения системы программного обеспечения на некотором этапе ее работы [1].

Фаулер: Архитектура — это общее понимание дизайна системы, включая то, как система делится на компоненты и как компоненты взаимодействуют через интерфейсы. [3]

Архитектурный стиль

Fielding: архитектурный стиль — это именованный, скоординированный набор архитектурных ограничений, который ограничивает роли и особенности архитектурных элементов [1]

Архитектурный стиль — это именованная коллекция архитектурных проектных решений, которые (1) применимы в данном контексте разработки, (2) ограничивают архитектурные проектные решения, которые являются специфическими для конкретной системы в этом контексте, и (3) выявляют полезные качества в каждом результирующая система [4]

ОТДЫХ или ОТДЫХ?

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

Соответствие ограничениям REST называется «RESTful». Или, другими словами: REST — это существительное, RESTful — это прилагательное.

гипертекста

На простом английском языке: Гипертекст — это текст со ссылками. На простом английском:

Википедия : Гипертекст — это текст, отображаемый на дисплее компьютера или других электронных устройствах со ссылками (гиперссылками) на другой текст, к которому читатель может получить немедленный доступ, или в котором текст может раскрываться постепенно на нескольких уровнях детализации.

Рой Филдинг: одновременное представление информации и элементов управления таким образом, что информация становится доступной, благодаря которой пользователь получает выбор и выбирает действия [слайд № 50]

гипермедиа

На простом английском языке: интерактивные мультимедиа. Если вы видите стенд в торговом центре с видео, звуком и т. Д., Который является мультимедийным. Если вы можете взаимодействовать с ним — нажимать на ссылки или управлять контентом с помощью кнопок и т. П., Это гипермедиа.

Википедия : Hypermedia, расширение термина гипертекст, является нелинейным носителем информации, который включает в себя графику, аудио, видео, простой текст и гиперссылки.

Рой Филдинг: Гипермедиа определяется наличием информации управления приложениями, встроенной в представление информации или в качестве уровня выше. [1]

Ресурс

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

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

Рой Филдинг: любая информация, которую можно назвать по имени, может быть ресурсом: документ или изображение, коллекция других ресурсов, не виртуальный объект (например, человек). Другими словами, любая концепция, которая может быть целью гипертекстовой ссылки автора, должна вписываться в определение ресурса. [1]

ОТДЫХ на практике: ресурс — это все, что мы показываем в Интернете, от документа или видеоклипа до бизнес-процесса или устройства. С точки зрения потребителя, ресурс — это все, с чем взаимодействует потребитель, продвигаясь к какой-то цели. [6]

URI — унифицированный идентификатор ресурса

Википедия : строка символов, используемая для идентификации имени ресурса

W3 : Унифицированные идентификаторы ресурсов (URI, также известные как URL) — это короткие строки, которые идентифицируют ресурсы в Интернете: документы, изображения, загружаемые файлы, службы, электронные почтовые ящики и другие ресурсы.

В чем разница между URI и URL?

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

Унифицированный указатель ресурса (URL) является подмножеством Унифицированного идентификатора ресурса (URI), который указывает, где идентифицированный ресурс доступен и механизм его получения ».

Таким образом, все URL-адреса являются URI, но все URI не являются URL-адресами. URI также могут быть URN (универсальное имя ресурса).

Или: URL-адреса и URN являются специальными формами URI.

По большей части, я думаю, что вы можете думать или URI и URL как одно и то же. Я могу быть пламенным из-за этого, но все становится проще!

Источники, ссылки, библиография

1. Архитектурные стили и проектирование сетевых программных архитектур (Fielding, 2000)
2. Немного ОТДЫХА и расслабления (Филдинг)
3. Кому нужен архитектор? (Фаулер)
4. Архитектура программного обеспечения: основы, теория и практика; Р. Н. Тейлор, Н. Медвидович и Е. М. Дашофи. Wiley, 2009.
5. Представительный государственный перевод (Википедия)
6. ОТДЫХ на практике (Уэббер; Парастатидис; Робинсон)
7. HTTP 1.1 (RFC 2616)