Как я должен кодировать словари в строки запроса HTTP GET?

Question

Строка запроса HTTP GET представляет собой упорядоченную последовательность пар ключ / значение:

?spam=eggs&spam=ham&foo=bar

Является, с определенной семантикой, эквивалентным следующему словарю:

{'spam': ['eggs', 'ham'], 'foo': bar}

Случается, что это хорошо работает для логических свойств запрашиваемой страницы:

?expand=1&expand=2&highlight=7&highlight=9
{'expand': [1, 2], 'highlight': [7, 9]}

Если вы хотите прекратить расширять элемент с идентификатором 2, просто извлеките его из expand значение и URL-адрес снова кодируют строку запроса.Однако, если у вас есть более модальное свойство (с 3 + вариантами), вы действительно хотите представить структуру следующим образом:

{'highlight_mode': {7: 'blue', 9: 'yellow'}}

Где значения соответствующих ключей id являются частью известного перечисления.Каков наилучший способ закодировать это в строку запроса?Я подумываю об использовании последовательности из двух кортежей следующим образом:

?highlight_mode=(7,blue)&highlight_mode=(9,yellow)

Редактировать: Также было бы неплохо узнать какие-нибудь имена которые ассоциируются с конвенциями.Я знаю, что их может и не быть, но приятно иметь возможность говорить о чем-то конкретном, используя название вместо примеров.Спасибо!

Answer 1

Обычный способ - сделать это следующим образом:

highlight_mode[7]=blue&highlight_mode[9]=yellow

AFAIR, довольно много серверных языков на самом деле поддерживают это "из коробки" и создадут хороший словарь для этих значений.

Answer 2

Я также видел, как люди JSON-кодируют вложенный словарь, затем дополнительно кодируют его с помощью BASE64 (или чего-то подобного), затем передают весь результирующий беспорядок в виде одного параметра строки запроса.

Довольно уродливый.

С другой стороны, если вам может сойти с рук использование POST, JSON - действительно хороший способ передавать такого рода информацию туда и обратно.

Answer 3

Во многих веб-фреймворках это кодируется иначе, чем то, что вы говорите.

{'foo': [1], 'bar': [2, 3], 'fred': 4}

было бы:

?foo[]=1&bar[]=2&bar[]=3&fred=4

Причина, по которой ответы массива должны отличаться от обычных ответов, заключается в том, что уровень декодирования может автоматически отличать менее распространенный случай foo (массив, в котором просто случайно есть один элемент) от чрезвычайно распространенного случая fred (один элемент).

Это обозначение может быть экстраполировано на:

?highlight_mode[7]=blue&highlight_mode[9]=yellow

когда у вас есть хэш, а не просто массив.

Я думаю, что это в значительной степени то, что делают Rails и большинство фреймворков, копируемых с Rails.

Пустые массивы, пустые хэши и отсутствие скалярного значения выглядят идентично в этой кодировке, но вы мало что можете с этим поделать.

Это [], кажется, вызывает всего несколько вспышек пламени.Некоторые считают это ненужным, потому что браузеру, транспортному уровню и кодировщику строк запроса все равно.Единственное, что волнует, - это автоматический декодер строк запроса.Я поддерживаю способ использования Rails [].Альтернативой было бы использование отдельных методов для извлечения скаляра и извлечения массива из строки запроса, поскольку нет автоматического способа определить, когда программе требуется [1], когда ей требуется 4.