Ревью 2 теория. Инструкция по созданию бизнесобъектов. Strategy это поведенческий паттерн, выносит набор алгоритмов в собственные классы и делает их взаимозаменимыми
 Скачать 0.74 Mb.
|
47. Структура HTTP?Каждое HTTP-сообщение состоит из трех частей, которые передаются в указанном порядке: 1. Стартовая строка (Starting line) — определяет тип сообщения. B первой строке содержится основная информация. Для запроса это HTTP-метод, путь, и версия протокола. Для ответа – статус: версия протокола, код ответа, и опциональное пояснение. Значения следуют именно в таком порядке, и разделяются пробелами. 2. Заголовки (Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения. Каждая последующая (до пустой) строка представляет заголовок. Заголовки – метаинформация сообщения в формате ключ-значение. Название отделяется от значения символом двоеточия. В заголовках приходят кодировка, размер тела, данные о кешировании, и т.д. Стандартный набор доступных заголовков описан в спецификации. Пользователь имеет право придумывать собственные заголовки – их принято снабжать префиксом X-. Для запроса обязателен заголовок Host. Тело сообщения (Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой. Тело сообщения может отсутствовать, но стартовая строка и заголовок являются обязательными элементами. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа — только тело сообщения. Для версии протокола 1.1 сообщение запроса обязательно должно содержать заголовок Host.  48. Стартовая строка?HTTP запросы — это сообщения, отправляемые клиентом, чтобы инициировать реакцию со стороны сервера. Стартовая строка состоит из трех элементов: 1. Метод HTTP, глагол (например, GET, PUT или POST) или существительное (например, HEAD или OPTIONS), описывающие требуемое действие. Например, GET указывает, что нужно доставить некоторый ресурс, а POST означает отправку данных на сервер (для создания или модификации ресурса, или генерации возвращаемого документа). 2. Цель запроса, обычно URL, или абсолютный путь протокола, порт и домен обычно характеризуются контекстом запроса. Формат цели запроса зависит от используемого HTTP-метода. Это может быть: 2.1. Абсолютный путь, за которым следует '?' и строка запроса. Это самая распространенная форма, называемая исходной формой (origin form). Используется с методами GET, POST, HEAD, и OPTIONS. Пример: POST / HTTP 1.1 GET /background.png HTTP/1.0 HEAD /test.html?query=alibaba HTTP/1.1 OPTIONS /anypage.html HTTP/1.0 2.2. Полный URL - абсолютная форма (absolute form), обычно используется с GET при подключении к прокси. Пример: GET http://developer.mozilla.org/ru/docs/Web/HTTP/Messages HTTP/1.1 2.3. Компонента URL «authority», состоящая из имени домена и (необязательно) порта (предваряемого символом ':'), называется authority form. Используется только с методом CONNECT при установке туннеля Пример: HTTP. CONNECT developer.mozilla.org:80 HTTP/1.1 2.4. Форма звездочки (asterisk form), просто "звездочка" ('*') используется с методом OPTIONS и представляет сервер. OPTIONS * HTTP/1.1 3. Версия HTTP, определяющая структуру оставшегося сообщения, указывая, какую версию предполагается использовать для ответа. Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так: GET URI — для версии протокола 0.9; Метод URI HTTP/Версия — для остальных версий. Где: Метод — тип запроса, одно слово заглавными буквами. В версии HTTP 0.9 использовался только метод GET, список методов для версии 1.1 представлен ниже. URI определяет путь к запрашиваемому документу. Метод – это последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Чувствителен к регистру. Сервер может использовать любые методы, не существует обязательных методов для сервера или клиента. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов. Кроме методов GET и HEAD, часто применяется метод POST. Версия — пара разделённых точкой цифр. Например: 1.0. 49. Заголовки (Headers) HTTP?HTTP Headers (заголовки HTTP) – это строки в HTTP-сообщении, содержащие разделенную двоеточием пару имя-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA. Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой. Заголовки HTTP позволяют клиенту и серверу отправлять дополнительную информацию с HTTP запросом или ответом. В HTTP-заголовке содержится не чувствительное к регистру название, а затем после (:) непосредственно значение. Пробелы перед значением игнорируются. HTTP-заголовки сопровождают обмен данными по протоколу HTTP. Они могут содержать описание данных и информацию, необходимую для взаимодействия между клиентом и сервером. Заголовки и их статусы перечислены в реестре IANA, который постоянно обновляется. Все заголовки разделяются на четыре основных группы: 1. General Headers (Основные заголовки) — должны включаться в любое сообщение клиента и сервера. 2. Request Headers (Заголовки запроса) — используются только в запросах клиента. 3. Response Headers (Заголовки ответа) — только для ответов от сервера. 4. Entity Headers (Заголовки сущности) — сопровождают каждую сущность сообщения. 50. Тело HTTP?Тело HTTP-сообщения (message-body), если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. Тело сообщения отличается от тела объекта (entity-body) только в том случае, когда применяется кодирование передачи, что указывается полем заголовка Transfer-Encoding. Поле Transfer-Encoding должно использоваться для указания любого кодирования передачи, применённого приложением в целях гарантирования безопасной и правильной передачи сообщения. Поле Transfer-Encoding — это свойство сообщения, а не объекта, и, таким образом, может быть добавлено или удалено любым приложением в цепочке запросов/ответов. Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения может быть добавлено в запрос, только когда метод запроса допускает тело объекта. Включается или не включается тело сообщения в сообщение ответа — зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом HEAD не должны включать тело сообщения, даже если присутствуют поля заголовка объекта (entity-header), заставляющие поверить в присутствие объекта. Никакие ответы с кодами состояния 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified) не должны содержать тела сообщения. Все другие ответы содержат тело сообщения, даже если оно имеет нулевую длину. Тело бывает не у всех запросов: запросы, собирающие (fetching) ресурсы, такие как GET, HEAD, DELETE, или OPTIONS, в нем обычно не нуждаются. Но некоторые запросы отправляют на сервер данные для обновления, как это часто бывает с запросами POST (содержащими данные HTML-форм). Тела можно грубо разделить на две категории: 1.Одноресурсные тела (Single-resource bodies), состоящие из одного отдельного файла, определяемого двумя заголовками: Content-Type и Content-Length. 2. Многоресурсные тела (Multiple-resource bodies), состоящие из множества частей, каждая из которых содержит свой бит информации. Они обычно связаны с HTML-формами. 51. HTTP сессия?Протокол HTTP и веб-серверы по природе своей являются stateless, и каждый новый запрос от клиента расценивается сервером как абсолютно новый, ничего не знающий об истории предшествующих обращений. Сессия — это диалоговое состояние между клиентом и сервером, включающее информацию о предыдущих запросах клиента и ответах сервера. В силу того, что протокол и сами веб-сервера не обеспечивают сохранение состояния, то единственной возможностью для этого является передача всей необходимой информации о запросе в нём самом. Чтобы этого не делать, каждый запрос от данного клиента сервер ассоциирует с некоторой уникальной информацией об установленной сессии (идентификатор сессии), пробрасывая её в каждом запросе и ответе. Для передачи данного UID наиболее популярными являются такие способы, как использование пользовательских cookies, скрытые поля формы и передача непосредственно в адресе запроса. При разработке веб-приложения, конечно, функцию генерации UID и последующей его передачи от клиента к серверу может взять на себя само приложение. Но тогда разработчик будет ответственен за все возможные обращения, каждый раз проверяя, а не забыл ли он передать это значение, при этом генерируя огромное количество boilerplate-кода. 52. Spring Boot?Spring Boot – это проект на уровне IO Execution (уровень выполнения) IO Spring Framework. |