Упорядочение параметров в URL about connector HOT 16 OPEN

https://stackoverflow.com/questions/1746507/authoritative-position-of-duplicate-http-get-query-keys

Чаще всего к параметрам которые могут быть массивом добавляют суффик [], например ?array[]=value1&array[]=value2. Все это вне спецификации. Кто-то берет первое, а массив только если есть суффикс. Кто-то всегда делает массив.

То, что появляется массив вдруг неожиданно - очень не удобно, конечно, такое разбирать потом.

Кажется важно поддержать суффикс [] чтобы для параметров с ним всегда создавался массив даже если такой элемент один. @vbondarevsky

Ну [] используют прям скажем не очень часто. Обычная практика это все же повторяющиеся ключи key=1&key=2 без [].
Сейчас логика кажется достаточно прямая. Один параметр - одно значение строкой. Несколько - массив строк.

P.S. Исходный issue все же про другое. Про кривые реализации серверной части, которые хотят строгий порядок параметров

from connector.

Обоснованный кейс, как решение предлагаю добавить возможность принимать в качестве параметров СписокЗначений - это упорядоченная структура, в качестве имени параметра использовать Представление, в качестве значения - Значение

from connector.

Попробовал добавить функционал, уперся в

В ЗаполнитьПараметрыЗапроса()

Если ПараметрыЗапроса.Получить(Ключ) <> Неопределено Тогда Если ТипЗнч(ПараметрыЗапроса[Ключ]) = Тип("Массив") Тогда ПараметрыЗапроса[Ключ].Добавить(Значение); Иначе Значения = Новый Массив; Значения.Добавить(ПараметрыЗапроса[Ключ]); Значения.Добавить(Значение); ПараметрыЗапроса[Ключ] = Значения; КонецЕсли; Иначе ПараметрыЗапроса.Вставить(Ключ, Значение); КонецЕсли;

Непонятно зачем формируется массив, по идее значением может быть только строка, возможно сериализованная.

from connector.

Непонятно зачем формируется массив, по идее значением может быть только строка, возможно сериализованная.

Может быть несколько значений
https://httpbin.org/anything/params?name=Иванов&name=Петров&salary=100000

from connector.

Если параметры запроса это соответствие массивов

То почему присваивается строка?

Которая получается из

Так же "хак" с добавлением в массив непонятен.

Если нужно, то обозначить на входе что параметры передаются массивами.

Если переделывать в список, то нужно убирать массивы вообще.

from connector.

https://stackoverflow.com/questions/1746507/authoritative-position-of-duplicate-http-get-query-keys

Чаще всего к параметрам которые могут быть массивом добавляют суффик [], например ?array[]=value1&array[]=value2.
Все это вне спецификации. Кто-то берет первое, а массив только если есть суффикс. Кто-то всегда делает массив.

То, что появляется массив вдруг неожиданно - очень не удобно, конечно, такое разбирать потом.

Кажется важно поддержать суффикс [] чтобы для параметров с ним всегда создавался массив даже если такой элемент один. @vbondarevsky

from connector.

https://stackoverflow.com/questions/1746507/authoritative-position-of-duplicate-http-get-query-keys

Чаще всего к параметрам которые могут быть массивом добавляют суффик [], например ?array[]=value1&array[]=value2. Все это вне спецификации. Кто-то берет первое, а массив только если есть суффикс. Кто-то всегда делает массив.

То, что появляется массив вдруг неожиданно - очень не удобно, конечно, такое разбирать потом.

Кажется важно поддержать суффикс [] чтобы для параметров с ним всегда создавался массив даже если такой элемент один. @vbondarevsky

"чаще всего []" - это специфичный костыль из PHP 3/4, который автоматически это преобразует в массив. В современном PHP такое делать уже давно не принято. На мой взгляд Коннектор не должен автоматически создавать массив если ключ с суффиксом "[]" только один

from connector.

Для меня в этом пребразовании в массив больше всего не нравится то что непонятно можешь получить массив или нет. Нет спецификации. Нужно писать постобработчики для того чтобы выделать один элемент в массив из одного элемента, заранее заявить что параметр должен быть массивом нельзя. Это некомфортно.

Какой то спецификации по тому нужно ли поддерживать порядок или нет я не нашел.

from connector.

Для меня в этом пребразовании в массив больше всего не нравится то что непонятно можешь получить массив или нет. Нет спецификации. Нужно писать постобработчики для того чтобы выделать один элемент в массив из одного элемента, заранее заявить что параметр должен быть массивом нельзя. Это некомфортно.

Какой то спецификации по тому нужно ли поддерживать порядок или нет я не нашел.

Неудобство понятно, однако я продолжаю считать, что это не сфера ответственности библиотеки Коннектора.
Здесь можно привести аналогию со СхемойXML и СписокXML. Без конкретной схемы ЧтениеXML не может знать список тут или один элемент. Когда видит несколько - преобразует в массив, когда один - в элемент

from connector.

И я согласен что проблему "массива" надо выносить в отдельный тикет

from connector.

https://stackoverflow.com/questions/1746507/authoritative-position-of-duplicate-http-get-query-keys
Чаще всего к параметрам которые могут быть массивом добавляют суффик [], например ?array[]=value1&array[]=value2. Все это вне спецификации. Кто-то берет первое, а массив только если есть суффикс. Кто-то всегда делает массив.
То, что появляется массив вдруг неожиданно - очень не удобно, конечно, такое разбирать потом.
Кажется важно поддержать суффикс [] чтобы для параметров с ним всегда создавался массив даже если такой элемент один. @vbondarevsky

Ну [] используют прям скажем не очень часто. Обычная практика это все же повторяющиеся ключи key=1&key=2 без []. Сейчас логика кажется достаточно прямая. Один параметр - одно значение строкой. Несколько - массив строк.

P.S. Исходный issue все же про другое. Про кривые реализации серверной части, которые хотят строгий порядок параметров

Для меня в этом пребразовании в массив больше всего не нравится то что непонятно можешь получить массив или нет. Нет спецификации. Нужно писать постобработчики для того чтобы выделать один элемент в массив из одного элемента, заранее заявить что параметр должен быть массивом нельзя. Это некомфортно.

Какой то спецификации по тому нужно ли поддерживать порядок или нет я не нашел.

Добавить параметр, что все значения всегда массив или функцию, которая строку будет всегда в массив заворачивать

from connector.

Хорошее видео к теме нескольких одинаковых параметров в запросе:
https://www.youtube.com/watch?v=QVZBl8yxVX0

from connector.

Увели нужный вопрос в другую тему )

Плохо, что нельзя самому собрать строку запроса в нужном порядке. Если б можно - вопрос частично закрылся бы.
УРЛ разбирается, дополняется, нарушается порядок.

Я тоже начал себе переделывать ПараметрыЗапроса как структуру/соотвествие на упорядоченный массив/список, а потом плюнул... много переделок в библиотеке.
И очень просто закостылил.
Передал служебное поле в ПараметрыЗапроса "ПорядокПолей" да и все.
Можно только начало ключа передать, когда имя параметра длинное типа:

PARAM1
PARAM2
PARAM3[KEY1][XXX1]
PARAM3[KEY1][XXX2]
PARAM3[KEY2]
PARAM4

и когда важно, чтобы PARAM* шли по порядку, а порядок KEY* - без разницы.
ПараметрыЗапроса.Вставить("ПорядокПолей", "PARAM1,PARAM2,PARAM3,PARAM4");

from connector.

Было бы здорово приводить конкретные кейсы где это нужно: на каких сайтах или API порядок важен.
емнип необходимость порядка параметров в URL никак не регламентируется в rfc, поэтому сейчас эта необходимость не особо обоснована.

Нужны конкретные примеры таких API

Увели нужный вопрос в другую тему )

Плохо, что нельзя самому собрать строку запроса в нужном порядке. Если б можно - вопрос частично закрылся бы. УРЛ разбирается, дополняется, нарушается порядок.

Я тоже начал себе переделывать ПараметрыЗапроса как структуру/соотвествие на упорядоченный массив/список, а потом плюнул... много переделок в библиотеке. И очень просто закостылил. Передал служебное поле в ПараметрыЗапроса "ПорядокПолей" да и все. Можно только начало ключа передать, когда имя параметра длинное типа:

PARAM1
PARAM2
PARAM3[KEY1][XXX1]
PARAM3[KEY1][XXX2]
PARAM3[KEY2]
PARAM4

и когда важно, чтобы PARAM* шли по порядку, а порядок KEY* - без разницы. ПараметрыЗапроса.Вставить("ПорядокПолей", "PARAM1,PARAM2,PARAM3,PARAM4");

from connector.

Было бы здорово приводить конкретные кейсы где это нужно: на каких сайтах или API порядок важен. емнип необходимость порядка параметров в URL никак не регламентируется в rfc, поэтому сейчас эта необходимость не особо обоснована.

Битрикс же! (гореть ему в аду ;)) ). Каждый метод на свой лад.
Например, этот task.elapseditem.getlist. Не получишь вторую страницу выборки, пока не перечислишь все "разделы" параметров по порядку.
PS: Битрикс известен еще регистрозависимостью и разным написанием одних и тех же параметров в разных методах. Условно FILTER filter - в разных методах по разному. Потому что "разработчик так видит".

from connector.

Было бы здорово приводить конкретные кейсы где это нужно: на каких сайтах или API порядок важен. емнип необходимость порядка параметров в URL никак не регламентируется в rfc, поэтому сейчас эта необходимость не особо обоснована.

Нужны конкретные примеры таких API

Честный знак Описание True API
https://znak-it.ru/wp-content/uploads/2022/04/true-api.pdf

Длина массива - от 1 до 1000 КИ
(без/с криптохвостом, криптохвост
перед обработкой удаляется) КИ в
списке перечисляются в формате
<URL>?codes=<КМ1>[&codes=<КМ
N>]

Вариант хранения параметров массив структур или ТЗ

from connector.