Как я должен кодировать словари в строки запроса 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 и снова введите код строки запроса. Однако, если у вас есть более модальное свойство (с 3+ вариантами выбора), вы действительно хотите представить такую ​​структуру:

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

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

?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.