Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

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

1 Изучение протокола HTTP как способа общения проектов в сети Интернет, веб-сервисы и REST-сервисы

1.1 Определение интернета

Интернeт представляет собой систему компьютерных сетей, объединённых для хранения и передачи информации с мировым масштабом. Также известен как «всемирная сеть», «сеть-интернет». В качестве технической базы выбран TCP/IP протокол. Благодаря интернету существует WWW (World Wide Web) и множество сервисов передачи данных.

Он очень стремительно развивается и охватывает всё большее число пользователей. Так, к 30 июня 2012 года число пользователей составляло более 2,5 млрд во всем мире (это более трети населения Земли). Ко второй половине 2015-го года их число достигло отметки в 3,3 млрд пользователей. С каждым годом сети передачи данных усовершенствуются, развиваются беспроводные сети (мобильные, wi-fi, спутниковые), что позволяет охватывать более широкую площадь. Благодаря росту дешевеет интернет-трафик, что позволяет пользоваться интернетом почти всем слоям населения.

1.2 Протокол HTTP

Дословно, это протокол передачи гипертекста. Является протоколом прикладного уровня для совместных, распределенных, информационных систем. Платформо-независим и применим в очень широком спектре задач.

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

Этот протокол используется в интернете с 1990-го года для передачи данных между системами. Он представляет собой механизм из запросов и ответов. Когда клиент обращается к серверу, он посылает HTTP-запрос, состоящий из HTTP-метода, названия ресурса URI, версию протокола (актуальная версия HTTP/1.1), MIME-подобное сообщение, которое содержит в себе модификаторы запроса, информацию клиента и тело запроса (может быть пустым). В ответ сервер отдает строку состояния, которая включает в себя версию протокола, код состояния, MIME-подобное сообщение, в котором содержится информация о сервере, метаинформацию объекта, и тело объекта, если оно есть.

Самым простым примером HTTP-запроса может быть запрос некоторого URI в интернет-браузере. При переходе по определенной ссылке происходит указанное на схеме в соответствие с рисунком 1:

Рисунок 1 – HTTP-запрос из интернет-браузера на интернет-страницу

– Клиент вводит ссылку в адресную строку интернет-браузера: например, http://dvgups.ru – главная страница сайта ДВГУПС;

– Интернет-браузер формирует запрос, устанавливает заголовки и отправляет HTTP запрос;

– Веб-сервер обрабатывает запрос, формирует данные, которые необходимо передать клиенту. Формируется запрос;

– Веб-сервер посылает HTTP-ответ клиенту, интернет-браузер принимает ответ, и предоставляет клиенту вид главной страницы сайта ДВГУПС.

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

1.3 Универсальные Идентификаторы Ресурсов (URI)

URI известны под многими именами: WWW адреса, Универсальные Идентификаторы Документов, Универсальные Идентификаторы Ресурсов (URI), и, в заключение, как комбинация Единообразных Идентификаторов Ресурса (Uniform Resource Locators, URL) и Единообразных Имен Ресурса (Uniform Resource Names, URN). HTTP определяет URL просто как строку определенного формата, которая идентифицирует – через имя, расположение, или любую другую характеристику - ресурс.

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

Например, перейдя по ссылке http://example.com — мы попадем на http-сервер ресурса, идентифицируемого как example.com, в то же время ftp://example.com — приведет нас на ftp-сервер того же самого ресурса.

В основном используются два вида URI – URL и URN. Главное различие – решаемая с их помощью задача:

URL – Uniform Resource Locator, выполняет задачу поиска ресурса;

URN – Uniform Resource Name, выполняет идентификацию ресурса.

Синтаксис URI:

URI могут представляться в абсолютной и относительной формах, в зависимости от контекста применения. Эти формы различаются тем, что абсолютные URI всегда начинаются с названия схемы (например, «http:» и «ftp:»). URI составлен из ограниченного набора символов, состоящих из цифр, букв и нескольких графических символов, все эти символы вписываются в кодировку US-ASCII (ASCII). Зарезервированное подмножество символов может использоваться, чтобы разграничить компоненты синтаксиса в URI, в то время как остающиеся символы: не зарезервированный набор и включая те зарезервированные символы, которые не действуют как разделители в данной компоненте URI, определяют данные идентификации каждого компонента.

Зарезервированные символы бывают двух типов:

– Главные разделители: символы, разделяющие URI на крупные компоненты («:», «/», «?», «#», «[», «]», «@»);

– Подразделители: символы, которые разделяют текущую крупную компоненту, на более мелкие составляющие («!», «$», «&», «'», «(» , «)», «*», «+», «,», «;», «=»).

Компоненты URI:

URI состоят из множества компонентов представленных на рисунке 2. Каждый компонент описан далее.

Scheme (схема):

Каждый URI начинается с названия схемы, которое относится к спецификации для присвоения идентификаторов в этой схеме. Синтаксисом URI является объединенная и расширяемая система наименований, причем, спецификация каждой схемы может ограничивать синтаксис и семантику идентификаторов, которые пользуются данной схемой.
Название схемы обязательно начинается с буквы и далее может быть продолжено любым количеством разрешенных символов. Например, http:, https:, ftp: и другие протоколы прикладного уровня.

Рисунок 2 – компоненты URI

Authority (Идентифицирующая ресурс часть):

Компонента authority является иерархической. Она начинается с двойного слеша(//) и заканчивается следующим слешем(/), знаком вопроса(?) или октоторпом(#) или концом URI.

Path (Путь):

Компонента пути содержит данные, чаще организованные иерархически, и которые, вместе с данными в компоненте запроса (Query), служит для идентификации ресурса в рамках схемы URI и authority (если данная компонента указана). Путь начинается со слеша (/) и заканчивается знаком вопроса (?), октоторпом (#) или концом URI.

Query (Запрос):

Компонента запроса содержит данные, организованные не иерархически, которые, вместе с данными компоненты пути (Path), служит для идентификации ресурса в рамках схемы URI и authority (если данная компонента указана). Запрос начинается с первого знака вопроса (?) и заканчивается октоторпом (#) или концом URI.

В запросе, как правило, передаются данные в формате «ключ = значение», рекомендуется передавать «значение» в процентно-кодированном виде. Это обусловлено тем, что в «значении» может находиться символ амперсанда(&), используемый для разделения пар «ключ = значение». Появление амперсанда(&) среди «значений» не может гарантировать дальнейшей целостности и корректности интерпретации данных запроса.

Fragment (Фрагмент):

Эта компонента даёт возможность реализовать косвенную идентификацию вторичного ресурса по отношению к первичному. Семантика не имеет ограничений, начинается с октоторпа (#) и заканчивается концом URI, и может включать в себя любые символы.

HTTP не накладывает ограничений на длину URI. Каждый сервер должен быть в состоянии обработать URI неограниченной длины любого ресурса, который они обслуживают. Если такая возможность отсутствует, то серверу следует возвращать код состояния 414 (URI запроса слишком длинный, Request-URI Too Long).

URL в HTTP:

HTTP-схема используется для доступа к сетевым ресурсам через протокол HTTP. Для него определен синтаксис и семантика следующего вида:

– Ссылка: "http:" "//" хост [ ":" порт ] [ абсолютный путь ]

– Хост: <допустимое доменное имя машины или IP адрес (в точечно-десятичной форме)>

– Порт: *Целое число в диапазоне от 1 до 65 535 (или 2¹⁶ – 1)

Если порт не указан – используется 80-й порт. Это означает, что размещенный на определенном сервере идентифицированный ресурс, который ожидает TCP соединений на некотором порте, хосте, и абсолютном пути. Если абсолютный путь не указан в URL, его необходимо рассматривать обрабатывать как "/" при определении запрашиваемого URI (Request-URI).

Сравнение URI:

Для того, чтобы сравнить два URI, рекомендуется использовать чувствительное к регистру пооктетное (octet-by-octet) сравнение. Существуют некоторые оговорки:

– Если порт не указан, то принимается заданный по умолчанию порт для запрашиваемого URI;

– Имена хостов необходимо сравнивать без учета регистра;

– Имена схем необходимо сравнивать без учета регистра;

– Если абсолютный путь не указан, то принимается как "/";

– Символы закодированы в виде "%HEX".

Например, следующие URI эквивалентны:

– http://abc.com:80/~smith/home.html

– http://ABC.com/%7Esmith/home.html

– http://ABC.com:/%7esmith/home.html

1.4 Заголовки HTTP сообщений

Каждый HTTP-запрос (сообщение HTTP), имеет поля общих заголовков (general-header), заголовков запроса (request-header), заголовков ответа (response-header), и заголовков объекта (entity-header). Каждое поле представляет собой пару «ключ : значение» (двоеточие обязательно). Названия полей регистронезависимы. Они также могут быть многострочными. Разработчикам рекомендуется придерживаться общего вида при создании HTTP конструкции, поскольку некоторые приложения не в состоянии обрабатывать конструкции, отличные от "общей формы".

Заголовок сообщения = "название поля":"значение поля" CRLF

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

1.5 Тело HTTP сообщения

Тело запроса (сообщения) (message-body) используется для передачи тела объекта (entity-body). Тело сообщения отлично от тела объекта, если к нему применено кодирование. Кодирование указывается с помощью заголовка Transfer-Encoding. Поле Transfer-Encoding является свойством сообщения, но не объекта, и может быть добавлено (удалено) любым из звеньев в цепи запросов/ответов. Данное поле необходимо указывать при всяком кодировании передаваемого сообщения.

При наличии в сообщении тела, в запрос добавляются заголовоки: длина сообщения (Content-Length) или Transfer-Encoding. Добавить тело сообщения в запрос возможно только если метод запроса и код ответа подразумевает возможность наличия тела объекта (entity-body).

Для метода HEAD ответы не могут содержать тело сообщения. Также не могут содержать тело сообщения ответы с кодами состояния 1xx (Информационные), 204 (Нет содержимого, No Content) и 304 (Не модифицирован, Not Modified). Все остальные методы и коды могут содержать тело сообщение, в том числе пустое.

1.6 HTTP запрос (Request)

Запроса от клиента к серверу состоит из нескольких строк. На первой строке указываются: метод, применяемый к ресурсу, идентификатор ресурса (URI) и версия HTTP протокола.

Структура у запроса имеет следующий вид, указанный на рисунке 3:

Запрос = Request-Line *(general-header | request-header | entity-header) CRLF [message-body].

Рисунок 3 – структура HTTP запроса

Рассмотрим каждую часть подробнее.

Первая строка, равнозначно строка запроса (Request-Line):

Строка запроса (Request-Line) начинается с лексемы метода, после неё указывается запрашиваемый URI (Request-URI), версия HTTP и CRLF (перенос строки). Разделяются элементы с помощью пробела.

Например, GET www.example.com HTTP/1.1

Метод (Method):

Данная лексема указывает на то, какой метод нужно применить к запрашиваемому ресурсу (Request-URI). Если нет возможности применить указанный метод к URI, то сервер должен возвращать ответ с кодом состояния 405 (метод не прмиеним, Method Not Allowed). В случае, если сервер не в состоянии распознать метод, сервер должен вернуть код состояния 501 (Не реализовано, Not Implemented). Каждый сервер обязан поддерживать и распознавать методы HEAD и GET.

Запрашиваемый URI (Request-URI):

URI идентифицирует ресурс запроса. Более подробно про URI было описано ранее.

Структура Request-URI: * | абсолютный_URI | абсолютный_путь

Характеристики

Список файлов ВКР