что такое request и response
Урок 3. Requests и responses, роутинг и контроллеры
Содержание
Requests и responses
Запросы и ответы в Drupal 8 представлены компонентом Symfony HttpFoundation (был рассмотрен в Уроке 2) и классами Request и Response соответственно.
Request
Объект запроса содержит информацию о клиентском запросе. Данные могут быть получены через паблик свойства класса:
Каждое свойство — это экземпляр класса ParameterBag (класс, который представляет собой контейнер для хранения пары ключ/значение). Соответственно все экземпляры данного класса имеют методы для получения/обновления данных, а также фильтрации входных значений.
Чтобы получить информацию о запрашиваемом пути в классе Request существует метод getPathInfo().
Для примера обратимся к странице example.com/example
В переменной $path получим значение /example.
Пример имитации запроса.
Примеры неполного списка команд для получения тех или иных значений от запроса
Значение которые пришли по урлу /example?foo=123 
Response
Response [2] объект хранит всю необходимую информацию для построения ответа клиенту. Конструктор класса Response принимает три аргумента:
Пример создания респонса.
Ответ также можно модифицировать после его создания
Класс Response содержит довольно большое количество методов для управления HTTP заголовками (setPublic(), setPrivate(), expire() и т.д.).
Для редиректа пользователя на другой урл компонент HttpFoundation имеет в своем арсенале класс RedirectResponse, наследуемый от базового класса Response. Пример редиректа
Роутинг и контроллеры
Друпаловская роутинговая система работает на основе компонента Симфони HttpKernel. Роут — это путь, определенный в Друпале, при обращении по которому возвращается определенный контент.
Как правило, большинство фреймворков или систем умеют управлять повторяющимися задачами (например роутинг, проверки доступа и т.д.), поэтому разработчики могут довольно просто создавать страницы приложения. HttpKernel компонент предоставляет интерфейс, который формализует процесс запроса и создание соответствующего ответа. Т.е. таким образом компонент является “сердцем” любого приложения или системы и не имеет значения насколько они отличаются по внутренней архитектуре.
Структура интерфейса HttpKernel приведена ниже.
Создание кастомного модуля
В данном пункте рассмотрим создание кастомного модуля. Для этого перво-наперво создадим папку нашего модуля в директории modules/custom. Данный модуль по мере написания статей и изучения новых материалов мы будет постоянно расширять и дополнять. Модуль не будет тривиальным (наподобие Hello world), а будет выполнять достаточно конкретную задачу: тянуть ленту новостей с какого-либо новостного портала. Имя модулю дадим соответствующее — news.
Итак в папке modules/custom создаем папку news.
В ней создаем файл news.info.yml. Содержимое данного файла приведено ниже
Все, модуль готов:) Этого вполне достаточно, чтобы модуль был отображен в панели управления и мы могли его включить. 
Домашнее задание
Создать модуль news, добавить на страницу admin/config под блоком Web Services ссылку News с описанием. Урл ссылки News — admin/config/services/news. По этому урлу отображать пустую страницу с заголовком News.
Для выполнения данного задания потребуется создать свой роутинг, также необходимо разрешить доступ к данной странице только группе «администраторы».
Типы HTTP-запросов и философия REST
Этот пост — ответ на вопрос, заданный в комментарии к одной из моих статей.
В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.
Итак, что же представляет из себя один из основных протоколов интернета? Педантов отправлю к RFC2616, а остальным расскажу по-человечески 🙂
Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.
Стартовые строки для запроса и ответа имеют различный формат — нам интересна только стартовая строка запроса, которая выглядит так:
где METHOD — это как раз метод HTTP-запроса, URI — идентификатор ресурса, VERSION — версия протокола (на данный момент актуальна версия 1.1).
Заголовки — это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.
Тело сообщения — это, собственно, передаваемые данные. В ответе передаваемыми данными, как правило, является html-страница, которую запросил браузер, а в запросе, например, в теле сообщения передается содержимое файлов, загружаемых на сервер. Но как правило, тело сообщения в запросе вообще отсутствует.
Пример HTTP-взаимодействия
Первая строка — это строка запроса, остальные — заголовки; тело сообщения отсутствует
Ресурсы и методы
Вернемся к стартовой строке запроса и вспомним, что в ней присутствует такой параметр, как URI. Это расшифровывается, как Uniform Resource Identifier — единообразный идентификатор ресурса. Ресурс — это, как правило, файл на сервере (пример URI в данном случае ‘/styles.css’), но вообще ресурсом может являться и какой-либо абстрактный объект (‘/blogs/webdev/’ — указывает на блок «Веб-разработка», а не на конкретный файл).
Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно — получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».
В игру вступает REST
REST (REpresentational State Transfer) — это термин был введен в 2000-м году Роем Филдингом (Roy Fielding) — одним из разработчиков протокола HTTP — в качестве названия группы принципов построения веб-приложений. Вообще REST охватывает более широкую область, нежели HTTP — его можно применять и в других сетях с другими протоколами. REST описывает принципы взаимодействия клиента и сервера, основанные на понятиях «ресурса» и «глагола» (можно понимать их как подлежащее и сказуемое). В случае HTTP ресурс определяется своим URI, а глагол — это HTTP-метод.
REST предлагает отказаться от использования одинаковых URI для разных ресурсов (то есть адреса двух разных статей вроде /index.php?article_id=10 и /index.php?article_id=20 — это не REST-way) и использовать разные HTTP-методы для разных действий. То есть веб-приложение, написанное с использованием REST подхода будет удалять ресурс при обращении к нему с HTTP-методом DELETE (разумеется, это не значит, что надо давать возможность удалить всё и вся, но любой запрос на удаление в приложении должен использовать HTTP-метод DELETE).
REST дает программистам возможность писать стандартизованные и чуть более красивые веб-приложения, чем раньше. Используя REST, URI для добавления нового юзера будет не /user.php?action=create (метод GET/POST), а просто /user.php (метод строго POST).
В итоге, совместив имеющуюся спецификацию HTTP и REST-подход наконец-то обретают смысл различные HTTP-методы. GET — возвращает ресурс, POST — создает новый, PUT — обновляет существующий, DELETE — удаляет.
Проблемы?
Да, есть небольшая проблема с применением REST на практике. Проблема эта называется HTML.
PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос.
Дело в том, спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно. Например, в Rack (механизм, на базе которого Ruby взаимодействует с веб-сервером; с применением Rack сделаны Rails, Merb и другие Ruby-фреймворки) в форму можно добавить hidden-поле с именем «_method», а в качестве значения указать название метода (например, «PUT») — в этом случае будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.
Формальная логика “request-response” в изучении английского: преимущества программистов
Я всегда утверждаю, что самые талантливые лингвисты — это программисты. Связано это с их образом мышления, или, если хотите, с некоторой профессиональной деформацией.
Для раскрытия темы приведу несколько историй из жизни. Когда в СССР был дефицит, а мой муж был маленьким мальчиком, его родители где-то достали колбасу и подали на стол на праздник. Гости ушли, мальчик посмотрел на оставшуюся на столе колбасу, нарезанную аккуратными кружками, и спросил, нужна ли она ещё. “Бери бери!” — разрешили родители. Ну, он взял, пошел во двор, и стал с помощью колбасы учить соседских кошек ходить на задних лапках. Папа с мамой увидели и возмутились разбазариванием дефицитного продукта. А мальчик недоумевал, и даже обиделся. Ведь он же не втихушку стащил, а честно спросил, нужна ли еще колбаса…
Нет нужды говорить, что этот мальчик, когда вырос, стал программистом.
К зрелому возрасту таких забавных историй у айтишника накопилось множество. Например, однажды я попросила мужа купить курицу. Покрупнее и побелее по цвету чтобы птичка была. Он с гордостью принес домой огромную белую… утку. Я спросила, неужели он хотя бы по цене (утка стоит гораздо дороже) не задумался, ту ли птицу он покупает? Ответом мне было: “Ну, ты же о цене ничего не говорила. Сказала, птичку покрупнее и побелее. Я и выбрал из всего ассортимента самую крупную и самую белую ощипанную птицу! Задачу выполнил.” Я облегченно выдохнула, поблагодарив про себя небеса за то, что в магазине в тот день не было индейки. В общем, на ужин была утка.
Ну, и масса других ситуаций, в которых человек неподготовленный может заподозрить жесткий троллинг и даже обидеться. Гуляем по восхитительному южному пляжу, я мечтательно говорю: “Эх, так хочется чего-нибудь вкусненького…” Он, оглядевшись, заботливо спрашивает: “Хочешь, нарву плодов кактуса?”
Я надулась, едко поинтересовавшись, не пришло ли ему случайно в голову сводить меня в уютное кафе с пирожными, например. Муж ответил, что кафе в округе не увидел, а вот плоды опунции, которые он заметил в зарослях кактуса, очень даже вкусны, и вполне могут удовлетворить мой запрос. Логично.
Обижаться? Обнять и простить? Посмеяться?
Данную особенность профессионального мышления, порой провоцирующую курьезы в быту, айтишники могут поставить себе на службу в нелегком деле изучения английского.
Проиллюстрированный выше способ мышления (не будучи психологом, рискну условно охарактеризовать его как формально-логический),
а) резонирует с некоторыми принципами работы человеческого подсознания;
б) как нельзя лучше резонирует с некоторыми аспектами грамматической логики английского.
Особенности подсознательного восприятия запроса
Психология считает, что человеческое подсознание понимает все буквально и не обладает чувством юмора. Как и компьютер, с которым айтишник “общается” больше времени, чем с людьми. Подслушала у одного практикующего психолога метафору: “Подсознание — это великан, у которого нет глаз, нет чувства юмора, и который всё понимает буквально. А сознание — это зрячий лилипут, который сидит на шее великана и им управляет.”
Какая команда считывается великаном-подсознанием, когда лилипут-сознание произносит: “Мне нужно изучить английский”? Подсознание принимает REQUEST: “изучить английский”. Простодушный “великан” усердно начинает работать над выполнением команды, выдавая RESPONSE: процесс изучения. Вы узнаете, что в английском есть герундий, есть глагол to be, есть активный залог, есть пассивный залог, есть видовременные формы, есть сложное дополнение и сослагательное наклонение, есть актуальное членение, есть синтагмы, и т.д.
Изучали ли вы язык? Да. “Великан” выполнил поставленную задачу — вы честно изучали язык. Овладели ли вы английским на практике? Вряд ли. Запроса на овладение подсознание не получало.
Чем же различается изучение и овладение?
Изучение — это анализ, расчленение целого на части. Овладение — это синтез, сборка частей в целое. Подходы, прямо скажем, противоположные. Методики у изучения и у практического овладения разные.
Если конечная цель — научиться пользоваться языком как инструментом, то и формулировать задачу следует буквально: “Мне нужно овладеть английским.” Будет меньше разочарований.
Каков request, таков и response
Как упоминалось выше, английскому языку присущ некий формализм. К примеру, на поставленный вопрос нельзя в английском ответить как угодно. Можно ответить лишь в той форме, в которой он задан. Таким образом, на вопрос “Have you eaten the cake?” можно ответить лишь в той же грамматической форме с have: “Yes, I have / No, I haven’t.” Никаких “do” или “am”. Точно так же, на “Did you eat the cake?” правильно будет ответить “Yes, I did / No, I didn’t.”, и никаких “had” или “was”. Каков вопрос, таков ответ.
У русскоязычных часто вызывает недоумение момент, когда в английском, чтобы разрешить что-то, необходимо ответить отрицательно, а чтобы запретить, — положительно. Например:
Ведь естественный инстинкт русскоязычного сознания — разрешая, ответить “да”, а запрещая, — “нет”. Почему же в английском все наоборот?
Формальная логика. Отвечая на вопрос в английском, мы откликаемся не столько на реальную ситуацию, сколько на грамматику предложения, которое слышим. А в грамматике у нас вопрос звучит: “Do you mind?” — “Возражаете ли Вы?”. Соответственно, отвечая “Yes, I do.” — собеседник, откликаясь на грамматическую логику, утверждает “Да, возражаю”, т.е., запрещает, а вовсе не разрешает действие, как было бы логично для ситуативной логики. Каков вопрос, таков и ответ.
Аналогичное столкновение ситуативной и грамматической логики провоцируют просьбы типа “Could you…?” Не удивляйтесь, если в ответ на Ваше:
… и спокойно продолжит свою трапезу, так и не передав вам соль. Вы его спросили, может ли он передать соль. Он ответил, что может. Вы ведь не попросили его передать ее вам: “Would you…?” Носители английского частенько так шутят. Возможно, истоки знаменитого английского юмора кроются как раз на стыке противоречия грамматической и ситуативной логики… Совсем как юмор программистов, не находите?
Таким образом, приступая к освоению английского, имеет смысл пересмотреть формулировку запроса. Ведь когда мы приходим, например, в автошколу, мы говорим: “Мне нужно научиться водить автомобиль”, а не “Мне нужно изучить автомобиль”.
Более того, работая с преподавателем, студент вступает во взаимодействие с его когнитивной системой. У преподавателя тоже есть подсознание, работающее, как у всех людей, по принципу “request-response”. Если преподаватель не настолько опытный, чтобы “переводить” запрос обучаемого на язык его реальных потребностей, подсознание преподавателя также может воспринять запрос ученика как запрос на изучение, а не на овладение. И преподаватель с энтузиазмом откликнется и удовлетворит запрос, но предложенная к изучению информация не будет являться реализацией истинной потребности студента.
“Бойтесь своих желаний” (С)? Ищите преподавателя-телепата, умеющего переводить ваши запросы на язык ваших реальных потребностей? Корректно формулируйте ‘request’? Необходимое подчеркнуть. При грамотном подходе к делу, лучше всех обучающихся английским должны владеть именно программисты, как из-за особенностей их мировосприятия, так и из-за особенностей английского языка как такового. Залог успеха — правильный подход.
Стандарт PSR7 — Веб-разработка на PHP
Архитектура любого серверного веб-фреймворка, опирается на особенности протокола HTTP. В первую очередь сюда входят понятия запроса (request) и ответа (response). Это значит что каждому веб-фреймворку, так или иначе, приходится реализовывать эти объекты у себя, повторяя то, что уже было сделано в других местах.
Чтобы избежать такой ситуации, был разработан стандарт PSR7. Цель PSR-7 предоставить общий набор интерфейсов для фреймворков, чтобы последние могли использовать одинаковые абстракции. Это позволит разработчикам писать переиспользуемый, независимый от фреймворка код. Сам стандарт довольно объёмный и не имеет смысла его дублировать. Здесь мы поговорим только о ключевых особенностях.
Request и Response, с точки зрения стандарта, представляют собой абстракцию поверх механизмов встроенных в сам PHP. Например, они полностью заменяют собой суперглобальные массивы, механизм загрузки файлов и многое другое.
Объекты запроса и ответа во фреймворке Slim имеют интерфейс соответствующий стандарту PSR-7. Пример на главной странице фреймворка как раз демонстрирует это:
getBody() возвращает специальный объект-поток (stream). Этот объект можно изменять, записывая туда данные.
Интерфейсы, описанные в PSR7, эмулируют работу HTTP. С помощью их методов можно как извлечь любую информацию из запроса, так и создать любой ответ.
Эти методы работают не только для запроса, но и для ответа. Дело в том, что оба эти интерфейса Request и Response, имеют общую часть, которая называется Message, другими словами, многие методы повторяются и одинаково работают в каждом из этих объектов.
Response
Ответ аккумулирует внутри себя то, что отправится клиенту, но он изначально не пустой, а содержит некоторые разумные умолчания:
А вот с изменением все не так просто. Главная отличительная черта этого интерфейса в том, что он построен в иммутабельном (неизменяемом) стиле и реализует текучий интерфейс (fluent interface). Ответ невозможно «изменить» (ниже будет одно исключение). Вместо этого, всегда возвращается новый объект.
По этой причине, во фреймворках, поддерживающих стандарт PSR-7, обработчик запроса всегда должен вернуть объект ответа, только в этом случае фреймворк узнает о том, как надо ответить на запрос.
Единственная часть в Response, которую можно менять – тело ответа. Это связано с техническими особенностями работы потоков в самом PHP. Подробнее об этом можно прочитать в документации
Несмотря на все это, PSR7 достаточно низкоуровневый стандарт. Он не ставил перед собой целью сделать работу с объектами ответа и запроса максимально удобной и простой. Задача была в эмуляции поведения HTTP. Поэтому помимо реализации стандартных интерфейсов, многие фреймворки создают дополнительные обертки поверх PSR7. Эти обертки уже дают много прикладных полезных методов. Одну из таких оберток мы начали использовать с самого начала: Slim-Http. Вот лишь небольшой список полезных функций этой библиотеки которые мы либо использовали, либо будем использовать:
Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.
Сообщения HTTP
Сообщения HTTP состоят из текстовой информации в кодировке ASCII, записанной в несколько строк. В HTTP/1.1 и более ранних версиях они пересылались в качестве обычного текста. В HTTP/2 текстовое сообщение разделяется на фреймы, что позволяет выполнить оптимизацию и повысить производительность.
Механизм бинарного фрагментирования в HTTP/2 разработан так, чтобы не потребовалось вносить изменения в имеющиеся APIs и конфигурационные файлы: он вполне прозрачен для пользователя.
HTTP запросы и ответы имеют близкую структуру. Они состоят из:
Запросы HTTP
Стартовая строка
Заголовки
Заголовки запроса HTTP имеют стандартную для заголовка HTTP структуру: не зависящая от регистра строка, завершаемая ( ‘:’ ) и значение, структура которого определяется заголовком. Весь заголовок, включая значение, представляет собой одну строку, которая может быть довольно длинной.
Существует множество заголовков запроса. Их можно разделить на несколько групп:
Тела можно грубо разделить на две категории:
Ответы HTTP
Строка статуса (Status line)
Стартовая строка ответа HTTP, называемая строкой статуса, содержит следующую информацию:
Пример строки статуса: HTTP/1.1 404 Not Found.
Заголовки
Заголовки ответов HTTP имеют ту же структуру, что и все остальные заголовки: не зависящая от регистра строка, завершаемая двоеточием ( ‘:’ ) и значение, структура которого определяется типом заголовка. Весь заголовок, включая значение, представляет собой одну строку.
Существует множество заголовков ответов. Их можно разделить на несколько групп:
Тела можно разделить на три категории:
Фреймы HTTP/2
Сообщения HTTP/1.x имеют несколько недостатков в отношении производительности:
Фреймы HTTP сейчас прозрачны для веб-разработчиков. Это дополнительный шаг, который HTTP/2 делает по отношению к сообщениям HTTP/1.1 и лежащему в основе транспортному протоколу. Для реализации фреймов HTTP веб-разработчикам не требуется вносить изменения в имеющиеся APIs; если HTTP/2 доступен и на сервере, и на клиенте, он включается и используется.
Заключение
Сообщения HTTP играют ключевую роль в использовании HTTP; они имеют простую структуру и хорошо расширяемы. Механизм фреймов в HTTP/2 добавляет ещё один промежуточный уровень между синтаксисом HTTP/1.x и используемым им транспортным протоколом, не проводя фундаментальных изменений: создаётся надстройка над уже зарекомендовавшими себя методами.