Когда мы должны использовать Query, а когда Body в HTTP?
Всем привет. Подскажите, пожалуйста, есть ли какие-то ограничения в спецификации HTTP / REST, которые устанавливают ограничение на использование Query или Body?
Сама концепция REST настолько размыта, что стандартного ответа на ваш вопрос нету. То что вы используйте и видите это чаще всего не REST в том академическом плане в каком он был создал.
Вот хорошее мнение на этот счет. Но я ни где не находил его подтверждения.
https://habr.com/ru/company/yandex/blog/265569/
На самом деле все предельно просто.
URL является частным случаем URI, который в свою очередь расшифровывается как «Uniform Resource Identifier». То есть это в первую очередь идентификатор ресурса. По нему мы находим ресурс, обращаемся к ресурсу, отличаем его от других ресурсов.
Query же, это такая же часть URI, как и host или path, и так же принимает участие в идентификации ресурса.
В Body же как раз содержатся данные, отправляемые ресурсу на обработку. Потому в GET запросах и нет тела, так как запрашивая данные ты не отправляешь никаких данных на обработку, но тебе нужно четко идентифицировать тот ресурс, от которого ты хочешь эти данные получить. А идентифицируешь ты его при помощи url, в том числе query, если нужно.
PATCH /user или PUT /user/password значения не имеет, но обычно разработчикам день программировать новые эндпоинты, поэтому используют более общий PATCH /user.
Стандартные query-параметры
Ограничение на количество возвращаемых результатов. По умолчанию — 50, максимум — 300.
Объекты с идентификатором больше указанного значения.
Объекты с идентификатором больше или равным указанному значению.
Объекты с идентификатором меньше указанного значения.
Объекты с идентификатором меньше или равным указанному значению.
Объекты, выданные или созданные после указанной даты. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, выданные или созданные после указанной даты включительно. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, выданные или созданные до указанной даты. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, выданные или созданные до указанной даты включительно. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, которые были в последний раз открыты после указанной даты. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, которые были в последний раз открыты после указанной даты включительно. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, которые были в последний раз открыты до указанной даты. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, которые были в последний раз открыты раньше указанной даты включительно. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, измененные после указанной даты. Дата приводится по UTC в формате ISO 8601 YYYY-MM-DDThh:mm:ss[.sss].
Объекты, измененные после указанной даты включительно. Дата приводится по UTC в формате ISO 8601 YYYY-MM-DDThh:mm:ss[.sss].
Объекты, измененные до указанной даты. Дата приводится по UTC в формате ISO 8601 YYYY-MM-DDThh:mm:ss[.sss]
Объекты, измененные до указанной даты включительно. Дата приводится по UTC в формате ISO 8601 YYYY-MM-DDThh:mm:ss[.sss]
Объекты с перекрытием больше указанного значения.
Объекты с перекрытием, больше или равным указанному значению.
Объекты с перекрытием меньше указанного значения.
Объекты с перекрытием, меньше или равным указанному значению.
Объекты, выданные или созданные после указанной даты. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, выданные или созданные после указанной даты включительно. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, выданные или созданные до указанной даты. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, выданные или созданные до указанной даты включительно. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, завершенные после указанной даты. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, завершенные после указанной даты включительно. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, завершенные до указанной даты. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Объекты, завершенные до указанной даты включительно. Дата приводится по UTC в формате ISO 8601: YYYY-MM-DDThh:mm:ss[.sss].
Задания с идентификатором больше указанного значения.
Задания с идентификатором, больше или равным указанному значению.
Задания с идентификатором меньше указанного значения.
Задания с идентификатором, меньше или равным указанному значению.
QUERY
Query – основной класс, для работы с БД, через него происходит выборка, запись, обновление и удаление данных. Также можно проводить определенную обработку данных, полученных из БД. Экземпляр класса получаем через фабрику (смотри раздел УСТАНОВКА).
Описание функций
Все функции класса условно можно разбить на 4 группы. Для удобства присвоим каждой группе свой цвет:
Функции all() и aggregator()
Проще всего рассмотреть принцип работы функций на основе примера. В качестве примера возьмём вот такую схему базы данных:
| mark (m) | |||
| id | student id | lesson id | mark |
|---|---|---|---|
| 1 | 1 | 1 | 3 |
| 2 | 1 | 1 | 4 |
| 3 | 1 | 2 | 2 |
| 4 | 1 | 2 | 2 |
| 5 | 1 | 2 | 3 |
| 6 | 1 | 4 | 5 |
| 7 | 2 | 1 | 2 |
| 8 | 2 | 1 | 3 |
| 9 | 2 | 2 | 5 |
| 10 | 2 | 4 | 4 |
| 11 | 2 | 3 | 3 |
| 12 | 2 | 3 | 2 |
| 13 | 2 | 2 | 5 |
| 14 | 2 | 3 | 3 |
| 15 | 2 | 1 | 2 |
| 16 | 3 | 4 | 2 |
| 17 | 3 | 1 | 5 |
| 18 | 3 | 2 | 2 |
| 19 | 3 | 4 | 3 |
| 20 | 3 | 3 | 4 |
| coursework (c) | |||
| id | student id | title | semester number |
|---|---|---|---|
| 1 | 1 | Архитектура и производительность серверных ЦП | 1 |
| 2 | 2 | Закон единства и борьбы противоположностей | 1 |
| 3 | 2 | Серверные платформы RISC/UNIX | 2 |
| 4 | 2 | Вредоносное программное обеспечение | 3 |
| 5 | 2 | Графическое программирование на Ms Fortran | 4 |
| 6 | 3 | «Азы» программирования и обучающие программы | 1 |
| 7 | 3 | История возникновения Интернета | 2 |
| student (s) | |||
| id | name | semester number | |
|---|---|---|---|
| 1 | Даша | 1 | |
| 2 | Маша | 4 | |
| 3 | Паша | 2 | |
| lesson (l) | |||
| id | name | ||
|---|---|---|---|
| 1 | КоМод | ||
| 2 | Матан | ||
| 3 | Физ-ра | ||
| 4 | Философия | ||
Зачастую при запросе к БД хочется получить не плоский ответ, а древовидный. К примеру, выполнив такой запрос:
Получим плоский результат:
Здесь данные из таблицы student дублируются, а мы бы хотели увидеть такой результат:
Чтобы добиться такого результата, необходимо в функцию all передать массив с опциями:
Рассмотрим более сложный пример. Допустим нам надо получить всех студентов с названием их курсовых и со всеми оценками по всем предметам. Мы бы хотели получить это не в плоском виде, а в древовидном, без дублей. Ниже приведен нужный запрос к БД и результат.
| student id | student name | semester number | coursework id | coursework semester | coursework title | lesson id | lesson | mark id | mark |
|---|---|---|---|---|---|---|---|---|---|
| с таблицы: student | с таблицы: coursework | с таблицы: lesson | с таблицы: mark | ||||||
| 1 | Даша | 1 | 1 | 1 | Архитектура и производительность серверных ЦП | 1 | КоМод | 1 | 3 |
| 1 | Даша | 1 | 1 | 1 | Архитектура и производительность серверных ЦП | 1 | КоМод | 2 | 4 |
| 1 | Даша | 1 | 1 | 1 | Архитектура и производительность серверных ЦП | 2 | Матан | 3 | 2 |
| 1 | Даша | 1 | 1 | 1 | Архитектура и производительность серверных ЦП | 2 | Матан | 4 | 2 |
| 1 | Даша | 1 | 1 | 1 | Архитектура и производительность серверных ЦП | 2 | Матан | 5 | 3 |
| 1 | Даша | 1 | 1 | 1 | Архитектура и производительность серверных ЦП | 4 | Философия | 6 | 5 |
| 2 | Маша | 4 | 2 | 1 | Закон единства и борьбы противоположностей | 1 | КоМод | 7 | 2 |
| 2 | Маша | 4 | 2 | 1 | Закон единства и борьбы противоположностей | 1 | КоМод | 8 | 3 |
| 2 | Маша | 4 | 2 | 1 | Закон единства и борьбы противоположностей | 1 | КоМод | 15 | 2 |
| 2 | Маша | 4 | 2 | 1 | Закон единства и борьбы противоположностей | 2 | Матан | 9 | 5 |
| 2 | Маша | 4 | 2 | 1 | Закон единства и борьбы противоположностей | 2 | Матан | 13 | 5 |
| 2 | Маша | 4 | 2 | 1 | Закон единства и борьбы противоположностей | 3 | Физ-ра | 11 | 3 |
| 2 | Маша | 4 | 2 | 1 | Закон единства и борьбы противоположностей | 3 | Физ-ра | 12 | 2 |
| 2 | Маша | 4 | 2 | 1 | Закон единства и борьбы противоположностей | 3 | Физ-ра | 14 | 3 |
| 2 | Маша | 4 | 2 | 1 | Закон единства и борьбы противоположностей | 4 | Философия | 10 | 4 |
| 2 | Маша | 4 | 3 | 2 | Серверные платформы RISC/UNIX | 1 | КоМод | 7 | 2 |
| 2 | Маша | 4 | 3 | 2 | Серверные платформы RISC/UNIX | 1 | КоМод | 8 | 3 |
| 2 | Маша | 4 | 3 | 2 | Серверные платформы RISC/UNIX | 1 | КоМод | 15 | 2 |
| 2 | Маша | 4 | 3 | 2 | Серверные платформы RISC/UNIX | 2 | Матан | 9 | 5 |
| 2 | Маша | 4 | 3 | 2 | Серверные платформы RISC/UNIX | 2 | Матан | 13 | 5 |
| 2 | Маша | 4 | 3 | 2 | Серверные платформы RISC/UNIX | 3 | Физ-ра | 11 | 3 |
| 2 | Маша | 4 | 3 | 2 | Серверные платформы RISC/UNIX | 3 | Физ-ра | 12 | 2 |
| 2 | Маша | 4 | 3 | 2 | Серверные платформы RISC/UNIX | 3 | Физ-ра | 14 | 3 |
| 2 | Маша | 4 | 3 | 2 | Серверные платформы RISC/UNIX | 4 | Философия | 10 | 4 |
| 2 | Маша | 4 | 4 | 3 | Вредоносное программное обеспечение | 1 | КоМод | 7 | 2 |
| 2 | Маша | 4 | 4 | 3 | Вредоносное программное обеспечение | 1 | КоМод | 8 | 3 |
| 2 | Маша | 4 | 4 | 3 | Вредоносное программное обеспечение | 1 | КоМод | 15 | 2 |
| 2 | Маша | 4 | 4 | 3 | Вредоносное программное обеспечение | 2 | Матан | 9 | 5 |
| 2 | Маша | 4 | 4 | 3 | Вредоносное программное обеспечение | 2 | Матан | 13 | 5 |
| 2 | Маша | 4 | 4 | 3 | Вредоносное программное обеспечение | 3 | Физ-ра | 11 | 3 |
| 2 | Маша | 4 | 4 | 3 | Вредоносное программное обеспечение | 3 | Физ-ра | 12 | 2 |
| 2 | Маша | 4 | 4 | 3 | Вредоносное программное обеспечение | 3 | Физ-ра | 14 | 3 |
| 2 | Маша | 4 | 4 | 3 | Вредоносное программное обеспечение | 4 | Философия | 10 | 4 |
| 2 | Маша | 4 | 5 | 4 | Графическое программирование на Ms Fortran | 1 | КоМод | 7 | 2 |
| 2 | Маша | 4 | 5 | 4 | Графическое программирование на Ms Fortran | 1 | КоМод | 8 | 3 |
| 2 | Маша | 4 | 5 | 4 | Графическое программирование на Ms Fortran | 1 | КоМод | 15 | 2 |
| 2 | Маша | 4 | 5 | 4 | Графическое программирование на Ms Fortran | 2 | Матан | 9 | 5 |
| 2 | Маша | 4 | 5 | 4 | Графическое программирование на Ms Fortran | 2 | Матан | 13 | 5 |
| 2 | Маша | 4 | 5 | 4 | Графическое программирование на Ms Fortran | 3 | Физ-ра | 11 | 3 |
| 2 | Маша | 4 | 5 | 4 | Графическое программирование на Ms Fortran | 3 | Физ-ра | 12 | 2 |
| 2 | Маша | 4 | 5 | 4 | Графическое программирование на Ms Fortran | 3 | Физ-ра | 14 | 3 |
| 2 | Маша | 4 | 5 | 4 | Графическое программирование на Ms Fortran | 4 | Философия | 10 | 4 |
| 3 | Паша | 2 | 6 | 1 | «Азы» программирования и обучающие программы | 1 | КоМод | 17 | 5 |
| 3 | Паша | 2 | 6 | 1 | «Азы» программирования и обучающие программы | 2 | Матан | 18 | 2 |
| 3 | Паша | 2 | 6 | 1 | «Азы» программирования и обучающие программы | 3 | Физ-ра | 20 | 4 |
| 3 | Паша | 2 | 6 | 1 | «Азы» программирования и обучающие программы | 4 | Философия | 16 | 2 |
| 3 | Паша | 2 | 6 | 1 | «Азы» программирования и обучающие программы | 4 | Философия | 19 | 3 |
| 3 | Паша | 2 | 7 | 2 | История возникновения Интернета | 1 | КоМод | 17 | 5 |
| 3 | Паша | 2 | 7 | 2 | История возникновения Интернета | 2 | Матан | 18 | 2 |
| 3 | Паша | 2 | 7 | 2 | История возникновения Интернета | 3 | Физ-ра | 20 | 4 |
| 3 | Паша | 2 | 7 | 2 | История возникновения Интернета | 4 | Философия | 16 | 2 |
| 3 | Паша | 2 | 7 | 2 | История возникновения Интернета | 4 | Философия | 19 | 3 |
Пагинация с агрегированным запросом считает только верхние, самые основные данные. В приведенном выше примере для пагинации будет только 3 строчки.
whereWithJoin()
$options рассмотрим на примере:
Внутри одной скобки псевдонимы будут одинаковые (использована одна таблица). Ниже в примерах это видно.
Бывает необходимо написать запрос в рамках одной таблицы с поиском по нескольким столбцам, причем условие по нескольким столбцам описывает одну сущность (со связью И), а нам нужно поискать несколько сущностей. К примеру в таблице t есть две колонки cl1 и cl2. Составим запрос на псевдокоде:
Данный запрос вернет нам пустую выборку, для корректной работы необходимо таблицу t сджойнить, это уже будет таблица t ‘, тогда правильный запрос будет:
На практике это может понадобиться при поиске по динамическим свойствам динамических объектов. Давайте рассмотрим этот вариант на примере.
Сделаем упрощенный, демонстрационный вариант. У нас есть таблица product, куда записываются новые, поступающие товары. У нее будет 2 колонки: тип товара и id. Так же будет табличка properties, где будут хранится все свойства товаров. В табличке val будут хранится id товара, id свойств этого товара и значения этих свойств. Вот содержимое таблиц:
К примеру пользователь на фронтенде сформировал следующее условие:
«Получить все товары у которых лошадиных сил меньше 100 или диагональ экрана меньше 6 дюймов. Также товары должны весить меньше тонны и быть в эксплуатации больше месяца.»
Как видим из результата запроса, мы получили 18 записей, хотя по сути тут всего 2 товара, давайте приведем результат к древовидному виду и избавимся от дублей с помощью функции aggregator() или выполнив запрос с массивом настроек агрегации:
Примеры
Пример 1
Необходимо получить список студентов и количество каждой из оценок (сколько 2, 3, 4 и 5) по всем предметам. Также нужно использовать постраничное разбиение, показать результаты первой страницы (по 2 записи на странице).
В sorts название столбцов пишутся без префиксов.
Для студентки Даши получить средний бал по всем предметам.
Пример 2
Пользователь должен иметь возможность получить всех студентов, которые подходят под указанные им критерии, а именно пользователь указывает оценки и массив id предметов, у которых должна встречаться такая оценка.
В результате будет сгенерирован примерно следующий sql запрос:
Использование параметров
Параметр служит способом простого хранения и управления значением, которое можно использовать повторно.
Параметры обеспечивают гибкость для динамического изменения выходных данных запросов в зависимости от их значения и могут использоваться для:
Создание параметра
Power Query предоставляет два простых способа создания параметров:
Из существующего запроса — Можно легко щелкнуть правой кнопкой мыши запрос, значение которого является простой неструктурированной константой, такой как, но не ограничена, датой, текстом или числом, и выбрать команду преобразовать в параметр.
Можно также преобразовать параметр в запрос, щелкнув правой кнопкой мыши параметр и выбрав преобразовать в запрос, как показано на следующем рисунке.
Свойства параметра
Параметр сохраняет значение, которое можно использовать для преобразований в Power Query. Помимо имени параметра и значения, которое он хранит, у него также есть другие свойства, которые предоставляют метаданные. Ниже приведены свойства параметра.
Имя — Укажите имя этого параметра, которое позволит легко распознать его и отличать от других параметров, которые вы можете создать.
Описание — Описание отображается рядом с именем параметра при отображении сведений о параметрах, что помогает пользователям, которые задают значение параметра, понять его назначение и его семантику.
Обязательное требование — Флажок указывает, могут ли следующие пользователи указывать, должно ли быть указано значение параметра.
Предлагаемые значения — Предоставляет пользователю предложение выбрать значение для текущего значения из доступных параметров:
Любое значение — Текущим значением может быть любое значение, указанное вручную.
Вы по-прежнему можете вручную ввести любое значение, которое требуется передать в параметр. Список предлагаемых значений служит только в качестве простых предложений.
Запрос — Использует запрос списка (запрос, вывод которого представляет собой список) для предоставления списка предлагаемых значений, которые позже можно выбрать для текущего значения.
Текущее значение — Значение, которое будет храниться в этом параметре.
Где использовать параметры
Параметр может использоваться различными способами, но чаще всего используется в двух сценариях:
В следующих разделах вы увидите пример для этих двух сценариев.
Аргумент Step
В настоящее время эта функция недоступна в Power Query в сети.
Например, можно просмотреть следующие запросы заказов с полями OrderID, Units и Margin.
Можно создать новый параметр с минимальным полем имени с типом десятичного числа и текущим значением 0,2, как показано на следующем рисунке.
Можно открыть запрос заказы и в поле поля выбрать параметр больше чем фильтр.
После нажатия кнопки ОК можно увидеть, что таблица отфильтрована с использованием текущего значения параметра.
Если изменить Текущее значение параметра минимального поля на 0,3, можно сразу же увидеть, как обновляется запрос заказов и отображаются только те строки, в которых маржа превышает 30%.
Множественные преобразования в Power Query предлагают эту возможность выбора параметра из раскрывающегося списка. Поэтому рекомендуется всегда искать и использовать преимущества параметров, которые могут предложить вам.
Аргумент пользовательской функции
Вы можете присвоить имя этой новой функции. В демонстрационных целях имя этой новой функции будет иметь значение MyFunction. После нажатия кнопки ОК в области запросы будет создана новая группа с именем новой функции. В этой группе вы найдете параметры, используемые для функции, запрос, который использовался для создания функции, и саму функцию.
Дополнительные сведения о создании пользовательских функций см. в статье Создание пользовательской функции.