Упорядочение параметров в URL

vbondarevsky / Connector

Коннектор: удобный HTTP-клиент для 1С:Предприятие 8

Apache License 2.0

638 stars 207 forks source link

Упорядочение параметров в URL #25

Open gennayo opened 4 years ago

gennayo commented 4 years ago

Коннектор принимает в качестве параметров в URL структуру или соответствие, которые не гарантируют порядок следования элементов. Возникают проблемы при взаимодействии с API, для которых порядок параметров в URL имеет значение.

leemuar commented 4 years ago

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

malikov-pro commented 4 years ago

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

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

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

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

vbondarevsky commented 4 years ago

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

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

https://github.com/vbondarevsky/Connector/blob/75b57af681e7f2d347232073941a097f519d6172/src/DataProcessors/%D0%A2%D0%B5%D1%81%D1%82%D1%8B/Ext/ObjectModule.bsl#L282

malikov-pro commented 4 years ago

Если параметры запроса это соответствие массивов https://github.com/vbondarevsky/Connector/blob/75b57af681e7f2d347232073941a097f519d6172/src/CommonModules/%D0%9A%D0%BE%D0%BD%D0%BD%D0%B5%D0%BA%D1%82%D0%BE%D1%80HTTP/Ext/Module.bsl#L1827

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

https://github.com/vbondarevsky/Connector/blob/75b57af681e7f2d347232073941a097f519d6172/src/CommonModules/%D0%9A%D0%BE%D0%BD%D0%BD%D0%B5%D0%BA%D1%82%D0%BE%D1%80HTTP/Ext/Module.bsl#L1854

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

https://github.com/vbondarevsky/Connector/blob/75b57af681e7f2d347232073941a097f519d6172/src/CommonModules/%D0%9A%D0%BE%D0%BD%D0%BD%D0%B5%D0%BA%D1%82%D0%BE%D1%80HTTP/Ext/Module.bsl#L1841

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

https://github.com/vbondarevsky/Connector/blob/75b57af681e7f2d347232073941a097f519d6172/src/CommonModules/%D0%9A%D0%BE%D0%BD%D0%BD%D0%B5%D0%BA%D1%82%D0%BE%D1%80HTTP/Ext/Module.bsl#L1848-L1851

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

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

zeegin commented 2 years ago

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

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

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

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

leemuar commented 2 years ago

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

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

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

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

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

vbondarevsky commented 2 years ago

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 все же про другое. Про кривые реализации серверной части, которые хотят строгий порядок параметров

zeegin commented 2 years ago

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

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

leemuar commented 2 years ago

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

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

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

leemuar commented 2 years ago

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

vbondarevsky commented 2 years ago

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 все же про другое. Про кривые реализации серверной части, которые хотят строгий порядок параметров

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

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

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

leemuar commented 2 years ago

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

240596448 commented 2 years ago

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

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

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

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

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

leemuar commented 2 years ago

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

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

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

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

Я тоже начал себе переделывать ПараметрыЗапроса как структуру/соотвествие на упорядоченный массив/список, а потом плюнул... много переделок в библиотеке. И очень просто закостылил. Передал служебное поле в ПараметрыЗапроса "ПорядокПолей" да и все. Можно только начало ключа передать, когда имя параметра длинное типа:
PARAM1
PARAM2
PARAM3[KEY1][XXX1]
PARAM3[KEY1][XXX2]
PARAM3[KEY2]
PARAM4
и когда важно, чтобы PARAM шли по порядку, а порядок KEY - без разницы. ПараметрыЗапроса.Вставить("ПорядокПолей", "PARAM1,PARAM2,PARAM3,PARAM4");

240596448 commented 2 years ago

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

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

malikov-pro commented 2 years ago

Было бы здорово приводить конкретные кейсы где это нужно: на каких сайтах или 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>]

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