1) Вопрос не вполне понятен. Что значит “передать строку в виде словаря”? Стрку можно передать как строку . Вероятно вы имели в виду
запись базы данных, но тут возникает вопрос 2
2) Собственно GET запрос это и есть словарь по структуре, свойствам и поведению. Смотрите:
https://www.linux.org.ru/forum/general/15883443?cid=15883457
это и есть пара ключ-значение, то есть разница только в синтаксисе
{'cid': 15883457} # это то же самое
3) Решение на первый взгляд кажется оооооочень ненадежным. Вообще, лучше бы вам дать больше информации о вашей артитектуре, потому что есть подозрение, что вы собираетесь выстрелить себе в ногу.
3.1) <обрабатываем, получаем результат> Очень сильно зависит от того, как именно вы что-то обрабатываете. Самый безобидный случай, когда ваша обработка это чистая функция.
читать Но в этом случае немедленно возникает вопрос, а зачем это вообще выносить в бэкенд. Нельзя ли весь расчет реализовать на клиенте и не гонять бессмысленные данные по сети. Если функция не чистая, то
3.2) Менее безобидный случай, когда обработка не подразумевает записи в БД, только чтение. В этом случае, ваша ссылка рано или поздно устареет. То есть данные, которые вы зашифровали в ссылке перестанут быть актуальными. Допустим, у вас есть таблица
id | Имя города | Население
1 | Москва | 20 000 000
1254 | Сосновка | 1058
и вы прихранили в ссылке
< a href='http://my_site/page?city_id=1254&population=1058'>
Сама природа ссылки запрещает делать такие вещи, потому что ссылку можно сохранить в истории браузера, сохнанить в избранном, передать по имейлу, ссылки сохраняются в индексе поисковиков, в веб-архивах и так далее. То есть в какой то момент ваш бэкенд начнет обрабатывать заведомо неверные данные. В вашей базе уже 1057 жителей (дадя Илья помер вчера и данные изменились), но переход по ссылке в лучшем случае выдаст устаревшие данные, а в плохом ваша логик арасчета вообще сломается и клиент получит какую-нибудь ерунду. Это может произойти например, если у вас есть скажем таблица процентного соотношения полов в городе. И при запросе вы эти данные считываете из БД. И вот у вас часть данных для обработки новые, а часть страрые. И результат вы получите дурацкий. Но самое страшное это если
3.3) Этот запрос изменяет состояние БД. Вот тут вам надо бить по рукам сразу, потому что есть даже не золотое, а бриллиантовое правило любого сетевого приложения -
никогда не доверяй клиенту.
В общем, кажется, я повторяю
кажется, что ваше решение плохое. Нужно больше информации. А еще мне кажется, что вы решаете проблему, которая давно уже решена, это называется кеширование данных, но я могу ошибаться. Можем продолжить разбор полетов, если вы сообщите какую именно задачу вы пытаетесь таким образом решить.