В каждом конкретном случае разработчику
нужно принимать одно решение из многих, неизбежно отказываясь от одних
возможностей в пользу других, причаливать к тому или иному берегу. Или
метаться между двух огней, искать компромиссы — такое тоже не редкость…
Метод GET привлекает разработчиков своей простотой— все переданные
таким способом параметры прочесть легче, нежели данные, отправленные
при помощи метода POST. Очевидные плюсы есть и для пользователя — все
параметры на виду, и более-менее искушенный серфер может править их
значения прямо в адресной строке браузера, во всей полноте ощущая свободу
«неофициальной» навигации (см. главу 4).
Но, как известно, палка о двух концах… Длинные URL с обилием
спецсимволов трудно запоминаются и порой даже вызывают недоверие у не слишком
подкованных пользователей. К тому же, излишняя раскрепощенность
посетителей не всегда бывает в интересах разработчика — например, она
совершенно неприемлема в тех случаях, когда требуется, чтобы некоторые из
параметров принимали только фиксированные значения из строго определенного
списка. А уж если речь идет об информации конфиденциального характера,
то тем более весьма нежелательно, чтобы такие данные выставлялись на
всеобщее обозрение. В этом смысле метод POST, конечно, несколько
безопаснее.
286 Часть II. Применение веб-технологий стороны клиента для создания сайтов
Главный недостаток метода GET— ограниченная протяженность строки
пользовательских параметров. Максимальная длина URL в каждом
конкретном случае зависит как от версии браузера, так и от настроек сервера — но в
любом случае растянуть пользовательские данные от Владивостока до Бреста
не получится. Я обычно ориентируюсь на «потолок» порядка килобайта.
Метод POST, напротив, не налагает никаких ограничений на объем
передаваемых данных, и именно в этом заключается основное его преимущество
перед GET. К сожалению, почти все достоинства метода POST на этом и
заканчиваются.
Органический недостаток метода POST — невозможность поставить прямую
гипертекстовую ссылку на страницу, сгенерированную на основе конкретных
значений параметров. Отсюда вытекает невозможность индексирования
подобных динамических отчетов поисковыми системами.
Еще один существенный недостаток заключается в нарушении логики работы
кнопки Назад — самого популярного элемента пользовательского
интерфейса браузера. Вернуться на страницу, сгенерированную при помощи метода
POST, после перехода с нее куда бы то ни было еще, довольно трудно.
Internet Explorer, например, выдаст сообщение: «Внимание: страница
устарела» с требованием нажать на кнопку Обновить, если намерения пользователя
вновь просмотреть злополучную страницу все же сколько-либо серьезны.
В ряде браузеров возникают трудности при сохранении веб-страниц,
сгенерированных динамически с применением метода POST, для локального
просмотра. Отмечаются также проблемы с распечаткой подобных документов.
В общем и целом, подводя итог, скажем, что с позиций заботы о
пользователях метод POST — мягко говоря, не самый лучший выбор. Так что при
проектировании сложных многошаговых приложений (например, интернет-
магазинов) метод POST нужно стараться использовать только там, где
требуется передача действительно больших объемов информации. При этом
желательно, чтобы логика работы приложения строилась таким образом, что
страницы, генерируемые на основе данных, отправляемых методом POST, не
требовали бы возврата к себе.
Основные элементы форм
Виды полей ввода, доступные для применения в веб-формах, в достаточной
степени разнообразны. Тем не менее все они описываются сравнительно
небольшим количеством HTML-тегов. К таковым относятся
,
И