Содержание
Типы HTTP-запросов и философия REST / Хабр
Этот пост — ответ на вопрос, заданный в комментарии к одной из моих статей.
В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.
Итак, что же представляет из себя один из основных протоколов интернета? Педантов отправлю к RFC2616, а остальным расскажу по-человечески 🙂
Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.
Стартовые строки для запроса и ответа имеют различный формат — нам интересна только стартовая строка запроса, которая выглядит так:
METHOD URI HTTP/VERSION,
где METHOD — это как раз метод HTTP-запроса, URI — идентификатор ресурса, VERSION — версия протокола (на данный момент актуальна версия 1.
1).
Заголовки — это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.
Тело сообщения — это, собственно, передаваемые данные. В ответе передаваемыми данными, как правило, является html-страница, которую запросил браузер, а в запросе, например, в теле сообщения передается содержимое файлов, загружаемых на сервер. Но как правило, тело сообщения в запросе вообще отсутствует.
Рассмотрим пример.
Запрос:
GET /index.php HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text/html Connection: close
Первая строка — это строка запроса, остальные — заголовки; тело сообщения отсутствует
Ответ:
HTTP/1.0 200 OK Server: nginx/0.6.31 Content-Language: ru Content-Type: text/html; charset=utf-8 Content-Length: 1234 Connection: close ... САМА HTML-СТРАНИЦА ...
.. САМА HTML-СТРАНИЦА ...
Вернемся к стартовой строке запроса и вспомним, что в ней присутствует такой параметр, как URI. Это расшифровывается, как Uniform Resource Identifier — единообразный идентификатор ресурса. Ресурс — это, как правило, файл на сервере (пример URI в данном случае ‘/styles.css’), но вообще ресурсом может являться и какой-либо абстрактный объект (‘/blogs/webdev/’ — указывает на блок «Веб-разработка», а не на конкретный файл).
Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно — получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».
Для разграничения действий с ресурсами на уровне HTTP-методов и были придуманы следующие варианты:
- GET — получение ресурса
- POST — создание ресурса
- PUT — обновление ресурса
- DELETE — удаление ресурса
Обратите внимание на тот факт, что спецификация HTTP не обязывает сервер понимать все методы (которых на самом деле гораздо больше, чем 4) — обязателен только GET, а также не указывает серверу, что он должен делать при получении запроса с тем или иным методом.
А это значит, что сервер в ответ на запрос DELETE /index.php HTTP/1.1 не обязан удалять страницу index.php на сервере, так же как на запрос GET /index.php HTTP/1.1 не обязан возвращать вам страницу index.php, он может ее удалять, например 🙂
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.
Методы HTTP запроса — W3Docs
❮ Назад
Вперед ❯
HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». Изначально этот протокол использовался для передачи гипертекстовых документов в формате HTML.
Сегодня он используется для передачи произвольных данных.
В основе HTTP — клиент-серверная структура передачи данных․ Клиент формирует запрос (request) и отправляет на сервер; на сервере запрос обрабатывается, формируется ответ (response) и передается клиенту.
HTTP не шифрует передаваемую информацию. Для защиты передаваемых данных используется расширение HTTPS (Hyper Text Transfer Protocol Secure), которое “упаковывает” передаваемые данные в криптографический протокол SSL или TLS.
HTTP запрос состоит из трех основных частей: строка запроса (request line), заголовок (message header) и тело сообщения (entity body). Тело сообщения не является обязательным параметром. Между заголовком и телом есть пустая разделительная строка.
В строке запроса указывается метод передачи, версия протокола HTTP и URL, к которому должен обратиться сервер. Заголовки содержат тело сообщения, передаваемые параметры и другие сведения. В теле сообщения могут находиться передаваемые в запросе данные.
Для того, чтобы указать серверу на то, какое действие мы хотим произвести с ресурсом, используется тип HTTP-запроса, который также называется HTTP метод. Существует несколько HTTP методов, которые описывают действия с ресурсами. Наиболее часто используемыми являются GET и POST.
Метод GET запрашивает информацию из указанного источника и не влияет на его содержимое. Запрос доступен для кеширования данных и добавления в закладки. Длина запроса ограничена (макс. длина URL — 2048).
Примечание: Строка запроса (имя/значение) отправляется в URL
/login-check.php?argument1=value1&argument2=value2
Синтакс кода
<form method="get">
First name: <input type="text" placeholder="Your name"><br/>
<input type="submit" value="Submit">
</form>Метод POST
Метод POST используется для отправки данных, что может оказывать влияние на содержимое ресурса.
В отличие от метода GET запросы POST не могут быть кешированы, они не остаются в истории браузера и их нельзя добавить в закладки. Запросы POST не ограничиваются в объеме.
Примечание: Отправляемые данные содержатся в теле запроса.
POST /login-check.php HTTP/1.1 Host: w3docs.com argument1=value1&argument2=value2
Синтакс кода
<form method="post">
First name: <input type="text" placeholder="Your name"><br/>
<input type="submit" value="Submit">
</form>Сравнение методов GET и POST
Кроме методов GET и POST methods используются другие методы, которые описывают действия с ресурсами.
Таблица кодов состояния HTTP
Метод HTTP-ЗАПРОСА
Метод HTTP-ЗАПРОСА
| Интернет-Черновик | Метод HTTP-ЗАПРОСА | ноябрь 2021 |
| Решке и др. | Истекает 13 мая 2022 г. | [Страница] |
Эта спецификация определяет новый HTTP-метод QUERY как безопасный идемпотентный метод.
метод запроса, который может содержать содержимое запроса.¶
Это примечание должно быть удалено перед публикацией в виде RFC.¶
Обсуждение этого проекта происходит в рабочей группе HTTP.
список рассылки ([email protected]), который находится в архиве по адресу
https://lists.w3.org/Archives/Public/ietf-http-wg/.¶
Информацию о рабочей группе можно найти по адресу https://httpwg.org/;
исходный код и список проблем для этого черновика можно найти по адресу
https://github.com/httpwg/http-extensions/labels/safe-method-w-body.¶
Изменения в этом проекте кратко изложены в Приложении A.2.¶
Copyright (c) 2021 IETF Trust и лица, указанные в качестве
авторы документа. Все права защищены.¶
Этот документ регулируется BCP 78 и юридическими документами IETF Trust.
Положения, касающиеся документов IETF
(https://trustee.ietf.org/license-info) действует на дату
публикации этого документа. Пожалуйста, ознакомьтесь с этими документами
внимательно, так как они описывают ваши права и ограничения с
отношении к этому документу. Компоненты кода, извлеченные из этого
документ должен включать текст упрощенной лицензии BSD, как описано в
Раздел 4.e Правовых положений о трастах и предоставляются без
гарантия, как описано в Упрощенной лицензии BSD.¶
Эта спецификация определяет метод запроса HTTP QUERY как средство
создание безопасного идемпотентного запроса, содержащего содержимое.¶
Чаще всего это желательно, когда данные, передаваемые в запросе,
слишком объемный, чтобы его можно было закодировать в URI запроса. Например, пока
это распространенный и интероперабельный запрос:¶
ПОЛУЧИТЬ /feed?q=foo&limit=10&sort=-опубликовано HTTP/1.
1
Хост: example.org
¶
если параметры запроса распространяются на несколько килобайт или более
data может и не быть, потому что многие реализации накладывают ограничения на их размер. Часто эти ограничения не
известна или может быть обнаружена заранее, потому что запрос может проходить через множество несогласованных
системы. Кроме того, представление некоторых данных в целевом URI неэффективно, поскольку
должен быть закодирован как действительный URI.¶
Кодирование параметров запроса непосредственно в URI запроса также эффективно
отбрасывает каждую возможную комбинацию входных данных запроса как отдельные
Ресурсы. В зависимости от приложения это может быть нежелательно.¶
В качестве альтернативы использованию GET многие реализации используют метод
Метод HTTP POST для выполнения запросов, как показано в примере.
ниже. В этом случае входными параметрами операции поиска являются
передается вместе с полезной нагрузкой запроса, а не с использованием
запрос URI.
¶
Типичное использование HTTP POST для запроса поиска¶
POST/канал HTTP/1.1 Хост: example.org Content-Type: application/x-www-form-urlencoded q=foo&limit=10&sort=-опубликовано
¶
Этот вариант, однако, страдает тем же основным ограничением, что и GET.
в том, что это неочевидно — при отсутствии конкретных знаний о
ресурс и сервер, на который отправляется запрос — это безопасный,
выполняется идемпотентный запрос.¶
Метод QUERY обеспечивает решение, которое охватывает пробел между использованием GET и POST. В качестве
с POST входные данные для операции запроса передаются вместе с полезной нагрузкой запроса.
а не как часть URI запроса. Однако, в отличие от POST, этот метод явно безопасен.
и идемпотентный, что позволяет использовать такие функции, как кэширование и автоматические повторные попытки.¶
Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «ДОЛЖЕН
НЕТ», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ»,
«МОЖЕТ» и «ФАКУЛЬТАТИВНО» в этом документе следует интерпретировать как
описано в BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они
появляются во всех столицах, как показано здесь.
¶
Метод QUERY используется для инициирования запроса на стороне сервера. в отличие
метод HTTP GET, который запрашивает, чтобы сервер вернул
представление ресурса, идентифицированного целевым URI
(как определено в разделе 7.1 [RFCHTTP]), ЗАПРОС
метод используется, чтобы попросить сервер выполнить операцию запроса
(описывается полезной нагрузкой запроса) по некоторому набору данных,
эффективный URI запроса. Полезная нагрузка возвращена в ответ на запрос.
нельзя считать представлением ресурса, идентифицированного
эффективный URI запроса.¶
Полезная нагрузка тела запроса определяет запрос. Реализации МОГУТ использовать
тело запроса любого типа содержимого с методом QUERY, при условии, что оно
имеет соответствующую семантику запроса.¶
Запросы QUERY безопасны и идемпотентны в отношении
ресурс, идентифицируемый URI запроса. То есть запросы QUERY не
изменить состояние целевого ресурса.
Однако при обработке
запрос QUERY, можно ожидать, что сервер выделит вычисления и память
ресурсы или даже создавать дополнительные HTTP-ресурсы, через которые
ответ можно получить.¶
Ожидается, что успешный ответ на запрос QUERY предоставит некоторые
указание на окончательную диспозицию операции. За
например, успешный запрос, который не дает результатов, может быть представлен
ответом 204 No Content. Если ответ включает содержание,
ожидается описание результатов операции.
В некоторых случаях сервер может косвенно ответить на запрос.
запрос, возвращая перенаправление 3xx с полем заголовка Location, указывающим
альтернативный URI запроса, из которого можно получить результаты
используя запрос HTTP GET. Различные ненормативные примеры успешного
Ответы на QUERY проиллюстрированы в Разделе 4.¶
Семантика метода QUERY меняется на «условный QUERY», если
сообщение запроса включает в себя If-Modified-Since, If-Unmodified-
Поскольку поле заголовка If-Match, If-None-Match или If-Range
([РЧТТП], раздел 13).
Условный запрос QUERY требует, чтобы запрос
выполняться только при обстоятельствах, описываемых условным
поле(я) заголовка. Однако важно отметить, что такие условия
оцениваются по состоянию самого целевого ресурса, а не
к собранным результатам поисковой операции.¶
2.1. Кэширование
Ответ на метод QUERY кэшируется; кэш МОЖЕТ использовать его для удовлетворения последующих
Запросы QUERY в соответствии с разделом 4 [HTTP-КЭШИНГ]).¶
Кэш-ключ для запроса (см. Раздел 2 [HTTP-КЭШИРОВАНИЕ]) ДОЛЖЕН
включить содержание запроса. При этом кэши ДОЛЖНЫ сначала нормализовать запрос
содержимого для удаления семантически незначительных различий, тем самым улучшая кеширование
эффективность, по:¶
- Удаление кодировок контента¶
- Нормализация, основанная на знании соглашений о форматах, на что указывает любой суффикс типа мультимедиа в поле Content-Type запроса (например, «+json»)¶
- Нормализация на основе знания семантики самого контента, как указано в поле Content-Type запроса. ¶
¶ Обратите внимание, что любая такая нормализация выполняется исключительно с целью создания ключа кэша; Это
не изменяет сам запрос.¶
Поле заголовка ответа «Accept-Query» МОЖЕТ использоваться сервером для
напрямую сигнализировать о поддержке метода QUERY при идентификации
конкретные типы носителей формата запроса, которые могут использоваться.¶
Accept-Query = 1#медиа-тип
¶
Поле заголовка Accept-Query указывает список медиафайлов, разделенных запятыми.
типы (с необязательными параметрами), как определено
Раздел 8.3.1 [RFCHHTTP].¶
Порядок типов, перечисленных в поле заголовка Accept-Query, не имеет значения.¶
В ненормативных примерах в этом разделе используется простой,
гипотетический синтаксис запроса на основе обычного текста на основе SQL с результатами
возвращаются как значения, разделенные запятыми.
Это сделано для иллюстрации
только цели. Реализации могут свободно использовать любой формат, который они хотят.
как запрос, так и ответ.¶
4.1. Простой ЗАПРОС с прямым ответом
Простой запрос с прямым ответом:¶
ЗАПРОС /контакты HTTP/1.1 Хост: example.org Content-Type: пример/запрос Принять: текст/csv выберите фамилию, имя, ограничение электронной почты 10
¶
Ответ:¶
HTTP/1.1 200 ОК Тип содержимого: текст/csv фамилия, имя, электронная почта Смит, Джон, [email protected] Джонс, Салли, [email protected] Дюбуа, Камилла, [email protected]
¶
4.2. Простой ЗАПРОС с косвенным ответом (303 См. Другое)
Простой запрос с косвенным ответом (303 см. Другое):¶
ЗАПРОС /контакты HTTP/1.1 Хост: example.org Content-Type: пример/запрос Принять: текст/csv выберите фамилию, имя, ограничение электронной почты 10
¶
Ответ:¶
HTTP/1.
1 303 См. Другое
Расположение: http://example.org/contacts/query123.
¶
Ответ на запрос выборки:¶
ПОЛУЧИТЬ /контакты/запрос123 HTTP/1.1 Хост: example.org
¶
Ответ:¶
HTTP/1.1 200 ОК Тип содержимого: текст/csv фамилия, имя, электронная почта Смит, Джон, [email protected] Джонс, Салли, [email protected] Дюбуа, Камилла, [email protected]
¶
Метод QUERY подлежит той же общей безопасности.
соображения, как и все методы HTTP, как описано в
[RFCHHTTP].¶
IANA просит добавить метод QUERY в
постоянный реестр на
(см. Раздел 16.1.1 [RFCHTTP]).¶
| Название метода | Сейф | Идемпотент | Спецификация |
|---|---|---|---|
| ЗАПРОС | Да | Да | Раздел 2 |
- [RFC2119]
- Брэднер, С. , «Ключевые слова для использования в RFC для обозначения уровней требований», BCP 14, RFC 2119, DOI 10.17487/RFC2119, ,
- [RFC8174]
- Лейба, Б., «Неоднозначность прописных и строчных букв в RFC 2119».Ключевые слова», BCP 14, RFC 8174, DOI 10.17487/RFC8174, ,
- [РЧХТТП]
- Филдинг, Р., изд., Ноттингем, М., изд., и Дж. Решке, изд., «Семантика HTTP», работа в процессе, Internet-Draft, draft-ietf-httpbis-semantics-19, ,
- [HTTP-КЭШИРОВАНИЕ]
- Филдинг, Р., изд., Ноттингем, М., изд., и Дж. Решке, изд., «Семантика HTTP», незавершенная работа, Internet-Draft, draft-ietf-httpbis-cache-19, ,
, «Ключевые слова для использования в RFC для обозначения уровней требований», BCP 14, RFC 2119, DOI 10.17487/RFC2119, , Этот раздел следует удалить перед публикацией в виде RFC.¶
А.1. Так как draft-ietf-httpbis-safe-method-w-body-00
- Использовать тип носителя «example/query» вместо неопределенного «text/query» (https://github.com/httpwg/http-extensions/issues/1450)¶
- В разделе 3 измените грамматику, чтобы просто определить значение поля (https://github.com/httpwg/http-extensions/issues/1470)¶
- Обновите спецификацию ядра HTTP до последней версии и соответствующим образом измените терминологию (https://github.com/httpwg/http-extensions/issues/1473)¶
- Ссылка на RFC 8174 и условия разметки bcp14 (https://github.com/httpwg/http-extensions/issues/1497)¶
- Справочник по обновлению HTTP (https://github.com/httpwg/http-extensions/issues/1524)¶
- Ослабить ограничение общего типа мультимедиа XML в теле запроса (https://github. com/httpwg/http-extensions/issues/1535)¶
com/httpwg/http-extensions/issues/1535)¶ А.2. Так как draft-ietf-httpbis-safe-method-w-body-01
- Добавить минимальное описание кешируемости (https://github.com/httpwg/http-extensions/issues/1552)¶
- Используйте «QUERY» в качестве имени метода (https://github.com/httpwg/http-extensions/issues/1614)¶
- Справочник по обновлению HTTP (https://github.com/httpwg/http-extensions/issues/1669)¶
Юлиан Решке
гринбайтс ГмбХ
Хафенвег 16
48155 Мюнстер
Германия
Электронная почта:
[email protected]
URI:
https://greenbytes.de/tech/webdav/
Ашок Малхотра
Электронная почта:
[email protected]
Джеймс М. Снелл
Электронная почта:
[email protected]
Методы запроса выражений свойств — Spring: Spring Data 2 Video Tutorial
Из курса: Spring: Spring Data 2
Методы запроса выражений свойств
“
— [Рассказчик] Для поиска в базе данных общего назначения встроенных методов поиска всех и поиска одного репозитория достаточно.
Но что нам делать, если мы хотим найти всех студентов очной формы обучения, или студентов с определенной фамилией, или студентов в пределах возрастного диапазона, или даже всех студентов, изучающих определенный курс. В этой главе показано, как использовать общие ресурсы Spring для запроса источника данных. Файлы упражнений используют JPA данных Spring, но извлеченные здесь уроки применимы к любому модулю данных Spring, который зависит от commons. Я хочу показать вам расширенную модель предметной области для университетского приложения, которую мы используем в этой главе. Таким образом, наряду со студентом у него есть атрибут человека. Студент может быть зачислен на несколько курсов, и у каждого курса есть инструктор, который является штатным сотрудником, и список обязательных курсов. Несколько курсов связаны с одним отделом, и у каждого отдела есть кафедра, которая также является штатной. Сущность персонала инкапсулирует атрибут человека в качестве члена. В этой главе основное внимание уделяется запросам данных Spring, но перед этим нам нужно загрузить базу данных h3 при запуске приложения.
Мы можем сделать это в основном классе под названием University Application. Таким образом, в University Application мы внедряем интерфейсы репозитория, реализуем интерфейс запуска командной строки, а затем мы должны реализовать для этого метод run и переопределить его. И мы заполним хранилище в памяти студентами, сотрудниками, отделами, курсами и предварительными условиями курса. Итак, вот наш список студентов. У нас пока только четыре ученика в этой школе. У нас есть несколько сотрудников. Есть деканы, есть профессора. Позвольте мне сделать это немного больше, чтобы поместиться. Есть три факультета: гуманитарные, социальные науки и естественные науки. И для каждого из них есть заведующий кафедрой: Дин Джонс, Дин Мартин, а Дин Джонс также является заведующим кафедрой социальных и гуманитарных наук. В рамках гуманитарных наук у нас есть курсы английского языка, и для каждого из курсов у нас есть профессор. И мы также ссылаемся в этом курсе на отдел, в котором он находится, и мы также отмечаем, что после того, как мы настойчивы, мы хотим добавить к нему какие-либо предварительные условия.
Таким образом, вы не можете сдать английский 202 или английский 201 без предварительного изучения английского 101. Итак, у нас есть наши курсы по естественным наукам и все предварительные условия, а также курсы по общественным наукам с их названиями. Три — это количество кредитов, которое дает курс, профессор и кафедра, на которой он находится. И по какой-то причине вы не можете изучать психологию, не изучая историю или английский язык. Таким образом, он может пересекать отделы. Таким образом, при запуске приложения это сохранит его в базе данных памяти h3, а когда оно остановится, память исчезнет, поэтому это должно запускаться каждый раз при запуске. Давайте посмотрим на студенческий репозиторий. И теперь у нас есть методы в нашем crud-репозитории для студенческого репозитория. Мы просто рассмотрим эти первые три. Таким образом, я нахожу по полной занятости, нахожу по возрасту и нахожу по фамилии участника. Какие ваши типичные вещи вы хотели бы посмотреть на студента. А очное мы знаем, это атрибут студента, и это булев тип.
Мы знаем, что возраст является атрибутом студента, и это целое число. И мы знаем, что у учащегося есть атрибут участника, а у участника есть атрибут фамилии, и это строка или ее параметр. Итак, эти методы запроса объявлены, но кто реализует эти методы? Хорошо, что это не я. И я запущу его только для того, чтобы доказать это. Итак, в демонстрациях запросов мы рассмотрим этот простой метод примера запроса. Таким образом, при запуске, просто запустив этот тест, он вызовет метод запуска университетского приложения и создаст экземпляры всех наших университетских объектов и придет к точке останова здесь в простых примерах запросов. Я сделаю это немного легче читать на одной странице. Итак, сначала мы собираемся найти всех студентов, которым 20 лет. Есть только один студент, которому 20 лет. Затем мы найдем студентов очной формы обучения. У нас трое студентов очной формы обучения. И мы найдем учеников с фамилией Доу. У нас есть два студента с фамилией Доу. Это чудо? Это магия? Ну нет, на самом деле это вовсе не волшебство.