Querystring Расширенный поиск, где имеется около 20 полей поиска

Я создаю страницу расширенного поиска, где есть около 20 полей поиска для фильтрации фильтров. Мой вопрос касается строки запроса. Является ли стандартной практикой веб-разработки сказать 20 параметров в querystring?

В результатах поиска отображаются большие таблицы данных. Есть ли альтернатива, которая все еще использует HTTP GET (querystring), если она не является стандартной? Я хотел бы, чтобы пользователи могли добавлять закладки в свои поисковые запросы.

2 голоса | спросил Rayshawn 3 PMpWed, 03 Apr 2013 16:18:06 +040018Wednesday 2013, 16:18:06

4 ответа


2

Я бы не стал беспокоиться о том, что в запросе есть много параметров. Нет ограничений на количество параметров, только общая длина URL (как упоминалось другими). Длинные запросы с большим количеством параметров обычно используются крупными сайтами. Например, в Google Картах легко построить запрос параметров 15.

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

Интересно, что Google Maps также не беспокоится о нарушении лимита 2000 символов. Вот URL, который он создал для моего тура по местам с длинными именами в районе Филадельфии:

https://local.google.com/maps?saddr=Philadelphia+International+Airport,+Essington+Avenue,+Philadelphia,+PA,+United+States&daddr=Philadelphia+Archery+%26+ Gun + Club + Эллсуорт + Street + Филадельфия, + PA + United + States + в: Филадельфия + Музей + в + Art + Benjamin + Franklin + Parkway, + Филадельфия, + PA + United + States + к: Северо-Восток + Филадельфия, + Филадельфия, + PA + United + States + к: Филадельфия + интернэшнл + Аэропорт, + Essington + авеню, + Филадельфия, + PA, + United + States + до: Филадельфия + аэропорт + флориста, + MacDade + Boulevard, + Филадельфия, + PA + United + States + в: Филадельфия + Музей + в + Art, + Benjamin + Franklin + Parkway, + Филадельфия, + PA, + United + States + до: Филадельфия + Семейный + суд + Юг + 11 + Street + Филадельфия, + PA + United + States + в: Филадельфия + Музей + в + Art, + Benjamin + Franklin + Parkway, + Филадельфия, + PA, + United + States + к: Erawan + Тайский + кухня, + Юг + двадцать третий + Street + Филадельфия, + PA + United + States + к: четыре + точек + на + Sheraton + Филадельфия + City + центр + Race + Street + Филадельфия, + PA + United + States + к: Philadelp ОВЗ + Музей + в + Art + Benjamin + Franklin + Parkway, + Филадельфия, + PA + United + States + к: Филадельфия + интернэшнл + Аэропорт, + Essington + Авеню, + Филадельфия, + PA, + United + государств + в: Филадельфия + Streets + департамента + Arch + улице + Филадельфия, + PA, + United + States + к: Дуб + Lane% 2F + Восток + Ок + Lane, + Филадельфия, + PA, + United + States + к : Филадельфия + международный + аэропорт + Эссингтон + Avenue, + Филадельфия, + PA + United + States & амп; гл = еп & амп; SLL = 40,283716, -77,036133 & амп; sspn = 3.582578,6.773071 & амп; геокод = FZxxYAIdUcqD-yHY0zdGlBUuPikvg6lgZsTGiTHY0zdGlBUuPg% 3BFeBcYQIdzSyF- yGcj_mKAfhviSnVvLzvHsbGiTGcj_mKAfhviQ% 3BFS3UYQIdhNSE-yHTwCkDIXYoiyn_kKhF5sXGiTHTwCkDIXYoiw% 3BFRVmYwIdt4yH-ykvmB-AjLPGiTH60vEMkAhnrA% 3BFZxxYAIdUcqD-yHY0zdGlBUuPikvg6lgZsTGiTHY0zdGlBUuPg% 3BFaKWYAIdt8iD-yFsINr-eokAkSmfV6fdfcPGiTFsINr-eokAkQ% 3BFS3UYQIdhNSE-yHTwCkDIXYoiyn_kKhF5sXGiTHTwCkDIXYoiw% 3BFeeZYQIdsCuF-yEClZG3nPycxilx2ebjKMbGiTEClZG3nPycxg% 3BFS3UYQIdhNSE-yHTwCkDIXYoiyn_kKhF5sXGiTHTwCkDIXYoiw% 3BFYGdYQIdRN-Е-yFe7_1dh5lMoCmBMp8cSMbGiTFe7_1dh5lMoA% 3BFSCuY QId9imF-YF-Sw5cubLO2il5juueK8bGiTF-Sw5cubLO2g% 3BFS3UYQIdhNSE-yHTwCkDIXYoiyn_kKhF5sXGiTHTwCkDIXYoiw% 3BFZxxYAIdUcqD-yHY0zdGlBUuPikvg6lgZsTGiTHY0zdGlBUuPg% 3BFWipYQIdwwqF-yH_vQ3XcJYw_Snrjd4cMsbGiTH_vQ3XcJYw_Q% 3BFTInYwIdNKKF-yk9j724FbfGiTFK_xFG6xNTDQ% 3BFZxxYAIdUcqD-yHY0zdGlBUuPikvg6lgZsTGiTHY0zdGlBUuPg & амп; OQ = фил & амп; dirflg = HT & амп; doflg = ПТК & амп; MRA = Ls & амп; т = м & амп; г = 12

Этот URL-адрес также работает в последних версиях Internet Explorer, поэтому, возможно, этот предел больше не существует. Информация об ограничении IE, связанная выше, восходит к источнику с 2006 года, поэтому предел, возможно, давно ушел.

Обновление: после дальнейшего тестирования я обнаружил, что Chrome (!) зажимает этот длинный URL-адрес. Так что, возможно, вам стоит беспокоиться об этом!

ответил 3 PMpWed, 03 Apr 2013 18:12:14 +040012Wednesday 2013, 18:12:14
1

Кажется немного странным иметь так много предметов, я бы предложил использовать сообщение и поместить содержимое в отправленные данные.

Однако вы сказали, что хотите разместить закладку на странице результатов, поэтому я думаю, что вам нужно сохранить ее в строке запроса, как вы делаете. Однако учтите, что строка запроса имеет максимальную длину в большинстве браузеров, например. IE ограничен 2048 символами, что может быть проблемой. См. https://stackoverflow.com/questions/812925 /что-это-заместитель максимальной длины возможно, из-а-строки запроса

ответил Ian 3 PMpWed, 03 Apr 2013 16:45:22 +040045Wednesday 2013, 16:45:22
0

Как объясняется в связанном с этим вопросе SO , технически нет предела длине URI, однако IE 8 и ниже поддерживает только до 2083 символов , поэтому, если есть вероятность, что ваша страница поиска может генерировать URL больше, чем это, вы должны реализовать закладок другим способом.

На этой странице есть предложения по использованию практического URL-адреса ограничение длины, сохраняя возможность закладок:

  
  1. Если имена полей занимают слишком много места, используйте вместо него фиксированный порядок полей
  2.   
  3. Выдавите любое поле, которое действительно не нужно заносить в закладки
  4.   
  5. [A] void большие десятичные числа - используйте только ту же точность, что и вы, и рассмотрите представление base-64 с использованием букв и цифр
  6.   
  7. В крайних случаях рассмотрим использование алгоритма gzip для сжатия вашего довольно, но чрезмерно длинного URL. Затем перекодируйте эти двоичные данные   в base64, используя только символы, которые являются законными по URL-адресам
  8.   
  9. Альтернативой является сохранение информации о состоянии в файле или базе данных. Затем вы можете сохранить только идентификатор, необходимый для поиска   эта информация снова в URL
  10.   
ответил Mike Partridge 3 PMpWed, 03 Apr 2013 17:55:17 +040055Wednesday 2013, 17:55:17
0

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

Возможное решение:

  • использовать тело HTTP POST для отправки произвольно устаревших данных
  • кэшируйте эти параметры поиска и создайте для него уникальный идентификатор
  • вызывать переадресацию браузера в форме http: //[your_query_url]? query_id = [generated_id]
  • , просто убедитесь, что вы [your_query_url] можете перевести идентификатор в запрос, используя кеш, чтобы легко генерировать ответ

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

ответил bunglestink 3 PMpWed, 03 Apr 2013 18:44:38 +040044Wednesday 2013, 18:44:38

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132