лекция. Лекция 3 WEB Технологии. Лекция 3 web технологии
 Скачать 1.33 Mb.
|
|
Особенность HTTP - HTTP не имеет состояния, но имеет сессию В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами (например, «куки» на стороне клиента, «сессии» на стороне сервера). Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования. Простыми словами, не существует связи между двумя запросами, которые последовательно выполняются по одному соединению. Но хотя ядро HTTP не имеет состояния, куки позволяют использовать сессии с сохранением состояния. Используя расширяемость заголовков, куки добавляются к рабочему потоку, позволяя сессии на каждом HTTP-запросе делиться некоторым контекстом, или состоянием. ЗАПРОСЫ И ОТВЕТЫ: ИХ СТРУКТУРА, ФОРМИРОВАНИЕ И МЕТОДЫ Существует два типа HTTP сообщений, запросы и ответы, каждый в своем формате. HTTP запросы и ответы формируются в строгой последовательности и соответствуют определенной структуре. Они имеют близкую структуру и состоят из следующих элементов: Стартовая строка (Starting line, Строка запроса) — определяет тип сообщения, описывае запрос, или статус (успех или сбой). Это всегда одна строка. Заголовки (Headers) — произвольный набор заголовков, определяющих запрос или описывающих тело сообщения, характеризуют тело сообщения, параметры передачи и прочие сведения. Представляют из себя несколько пар значений, разделённых двоеточиями. Тело сообщения (Message Body) — непосредственно данные сообщения (например, содержимое HTML-формы) или отправляемый в ответ документ. Наличие тела и его размер определяется стартовой строкой и заголовками HTTP. Обязательно должно отделяться от заголовков пустой строкой. Тело сообщения может отсутствовать, но стартовая строка и заголовок являются обязательными элементами. Стартовую строку вместе с заголовками сообщения HTTP называют головой запроса, а его данные - телом.  HTTP- запросы (Requests)  Каждое HTTP-запрос состоит: Стартовая строка, которая в свою очередь состоит из 3-х элементов: Метод HTTP - это метод, который сообщает, какой метод HTTP используется. Чаще всего используется метод GET. Метод GET извлекает ресурс с веб-сервера, и поскольку у GET нет тела сообщения, после заголовка ничего не требуется. (О методах HTTP подробней ниже) Цель запроса, обычно URL, или абсолютный путь протокола, порт и домен обычно характеризуются контекстом запроса. Версия HTTP - используемая версия HTTP. Версия 1.1. является наиболее распространенной для большинства браузеров, однако, версия 2.0 становится популярнее. Заголовки (Headers) – может быть один или несколько заголовков. Эти значения могут быть самыми разными, но наиболее распространенными являются: Host - содержит имя сайта, наличие такого заголовка позволяет хостить несколько сайтов на одном IP адресе) User-Agent - дополнительная информация об используемом браузере, который по задумке должен обозначать вид используемого браузера, а на практике сложным образом описывает список поддерживаемых браузером технологий. Accept - определяет формат данных в ответе, который нужен клиенту Connection – «close» означает, что клиент хочет закрыть TCP соединение сразу после получения ответа от сервера. Тело сообщения (Message Body) - оно бывает не у всех запросов: запросы, собирающие ресурсы, такие как GET, HEAD, DELETE, или OPTIONS, в нем обычно не нуждаются. Если запрос сформирован правильно, и сервер функционирует нормально, и сеть в порядке то в ответ на HTTP пакет от клиента придёт ответ, который выглядит примерно вот так: HTTP- ответы (Responses)  Структура HTTP ответа: Строка статуса (status line) Стартовая строка ответа HTTP, называемая строкой статуса, содержит следующую информацию: Версию протокола, обычно HTTP/1.1. Код состояния (status code), показывающая, был ли запрос успешным. Примеры: 200, 404 или 302 Пояснение (status text). Краткое текстовое описание кода состояния, помогающее пользователю понять сообщение HTTP. Пример строки статуса: HTTP/1.1 404 Not Found. Заголовки Имеют ту же структуру, что и все остальные заголовки: не зависящая от регистра строка, завершаемая двоеточием (':') и значение, структура которого определяется типом заголовка. Тело Опционально, содержит пересылаемый ресурс. Методы HTTP запроса Для того, чтобы указать серверу на то, какое действие мы хотим произвести с ресурсом, используется тип HTTP-запроса, который также называется HTTP метод. HTTP метод указывает, какое желаемое действие выполнится для данного ресурса, и представляет собой последовательность из любых символов, кроме управляющих и разделителей. Обратите внимание, что название метода чувствительно к регистру. Метод HTTP (method) – это чаще глагол (например, GET, PUT или POST), но может быть и существительное (например, HEAD или OPTIONS), описывающие требуемое действие. Эти методы запроса иногда в англоязычной терминологии называются HTTP глаголами (verb). Существует несколько HTTP методов, которые описывают действия с ресурсами, но наиболее распространёнными методами являются GET и POST. Каждый сервер обязан поддерживать как минимум методы GET и HEAD. GET Метод GET запрашивает информацию из указанного источника и не влияет на его содержимое. GET-запросы не изменяют состояние ресурса GET-запросы должны только получать данные Запрос не имеет тела Запрос доступен для кеширования данных и добавления в закладки Строка запроса (имя/значение) отправляется в URL после символа «?»: /login-check.php?argument1=value1&argument2=value2 Длина запроса ограничена (макс. длина URL - 2048) С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса. Согласно стандарту HTTP, запросы типа GET считаются идемпотентными. Идемпотентность— свойство объекта или операции при повторном применении операции к объекту давать тот же результат, что и при первом. Метод HTTP является идемпотентным, если повторный идентичный запрос, сделанный один или несколько раз подряд, имеет один и тот же эффект, не изменяющий состояние сервера. Кроме обычного метода GET, различают ещё: Условный GET — содержит заголовки If-Modified-Since, If-Match, If-Range и подобные; Частичный GET — содержит в запросе Range. Порядок выполнения подобных запросов определён стандартами отдельно. POST Предназначен для передачи необработанных данных на сервер (для обработки и хранения) Метод POST используется для отправки данных, что может оказывать влияние на содержимое ресурса Запрос имеет тело В отличие от метода GET запросы POST не могут быть кешированы, они не остаются в истории браузера и их нельзя добавить в закладки Запросы POST не ограничиваются в объеме Отправляемые данные содержатся в теле запроса Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер. В отличие от метода GET, метод POST не считается идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться очередная копия этого комментария). В результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location. Сообщение ответа сервера на выполнение метода POST не кэшируется. Сравнение методов GET и POST
HEAD Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения. Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше — копия ресурса помечается как устаревшая. PUT PUT заменяет все текущие представления ресурса данными запроса. Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существует ресурс, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-*, передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented). Сообщения ответов сервера на метод PUT не кэшируются. Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу. Другими словами, разница между PUT и POST состоит в том, что PUT является идемпотентным: повторное его применение дает тот же результат, что и при первом применении (то есть у метода нет побочных эффектов), тогда как повторный вызов одного и того же метода POST может иметь такие эффекты, как например, оформление одного и того же заказа несколько раз. PATCH PATCH используется для частичного изменения ресурса. Аналогичен PUT, но для передачи фрагмента данных. DELETE DELETE удаляет указанный ресурс. OPTIONS OPTIONS показывают какие HTTP-методы доступны для конкретного URL-адреса. Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса. В ответ серверу следует включить заголовок Allow со списком поддерживаемых методов. Также в заголовке ответа может включаться информация о поддерживаемых расширениях. Пример: Для того, чтобы узнать какие методы запросов поддерживаются сервером, можно воспользоваться curl направить OPTIONS запрос:  Ответ на запрос содержит Allow (en-US) заголовок с поддерживаемыми методами:  Предполагается, что запрос клиента может содержать тело сообщения для указания интересующих его сведений. Формат тела и порядок работы с ним в настоящий момент не определён; сервер пока должен его игнорировать. Аналогичная ситуация и с телом в ответе сервера. Для того, чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку — «*». Запросы «OPTIONS * HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1. Результат выполнения этого метода не кэшируется. TRACE TRACE выполняет вызов возвращаемого тестового сообщения с ресурса. Возвращает полученный запрос так, что клиент может увидеть, какую информацию промежуточные серверы добавляют или изменяют в запросе. CONNECT CONNECT устанавливает "туннель" к серверу, определённому по ресурсу. Преобразует соединение запроса в прозрачный TCP/IP-туннель, обычно чтобы содействовать установлению защищённого SSL-соединения через нешифрованный прокси. WEB API API (Application Programming Interface) - интерфейс для программирования приложений. Набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах. API может отдавать данные в отличном от стандартного HTML формате, благодаря чему им удобно пользоваться при написании собственных приложений. Сторонние общедоступные API чаще всего отдают данные в одном из двух форматов: XML или JSON. КОДЫ ОТВЕТОВ HTTP Каждый HTTP-ответ должен содержать код состояния HTTP, сообщающий результат запроса. Код ответа (Код состояния, Код возврата, Cause code, Reason code, Status code, Disconnect code и т. д.) — ответ узла (сервера) на запрос в виде цифрового кода. Характеризует то или иное событие протокола или технологии, произошедшее на отвечающей стороне: успешное или неуспешное выполнение и т. д. Нередко коды ответа сопровождаются лаконичным комментарием (на английском языке), а в ответном сообщении вместе с цифровым кодами его расшифровкой может передаваться другая необходимая информация (например, запрошенные данные). Знание кодов ответа и ошибок позволяет пользователям, разработчикам и обслуживающему персоналу системы эффективно заниматься анализом проблем. Получив код ответа, автор запроса может сделать выводы о характере события и продолжить работу или завершить её, согласно ситуации. Коды ответа очень часто используется в архитектуре клиент-сервер, однако применение не ограничивается только ей и могут использоваться для взаимодействия равнозначных узлов/приложений в рамках соответствующего протокола. В зависимости от сферы применения коды завершения могут быть общепринятыми и узкоспециальными. Коды сгруппированы в 5 классов. Их группируют по первой цифре: |