GET или POST? Сравнительный анализ методов передачи данных

Начинающему веб-технологу, вероятно, на первых порах будет вполне достаточно тех сведений о протоколе HTTP, что были изложены в главе 1.
Тем не менее, считаю целесообразным поведать о некоторых особенностях методов GET и POST более подробно, ибо даже опытные разработчики зачастую упускают в своей повседневной практике самые что ни на есть ключевые концепции, не уделив им должного внимания в начале пути…
Итак, мы выяснили, что оба метода могут использоваться для передачи пользовательских данных от клиента серверу. А не задумывались ли вы над тем, почему тогда у этих самых методов прямо противоположные названия? Ведь post в буквальном переводе с английского — «отправлять, посылать по почте», а get — напротив, «брать, получать».
Порой даже тот, кто в деталях представляет себе, как происходит взаимодействие клиента и сервера в случае передачи пользовательских параметров различными способами, обычно оказывается не в состоянии объяснить смысл этой терминологической головоломки. Между тем, именно знание буквальных переводов английских слов post и get способно дать новичку возможность никогда не путать соответствующие методы и четко понимать их сущность.
Название метода GET подразумевает, что пользователь хочет «взять», «получить» ресурс, обладающий определенным URL. Например, таким:
http://www.somewebsite.ru/script.php?параметр_1=значение_1&параметр_2=
?значение_2&...&параметр_N=значение_N
С формальной точки зрения совсем не важно, что после вопросительного знака следуют какие-то специфичные данные — это просто составная часть адреса запрашиваемого ресурса.
Метод POST же отличается тем, что заданные пользователем значения параметров именно «отправляются», «отсылаются» серверу в теле HTTP-сообщения запроса как некий «полезный груз»; URL же запрашиваемого ресурса при этом не подвергается никаким модификациям.
Как видите, противоречий в терминологии нет, названия методов говорят сами за себя.
Пользовательские параметры, переданные при помощи метода POST, по умолчанию представляются точно таким же образом, как и при использовании метода GET:
параметр_1=значение_1&параметр_2=значение_2&...&параметр_N=значение_N
Но благодаря применению атрибута enctype здесь уже возможны и другие варианты, поскольку отправка пользовательских данных в теле HTTP-запроса не сопряжена с драконовскими ограничениями, определяемыми допустимым форматом URL.
Но зачем нам два метода, неужто не хватает одного? Дело в том, что нет в мире совершенства, идеального и универсального средства, с успехом справляющегося с любой задачей. У каждого из методов — свои индивидуальные особенности характера, приемлемые в одних ситуациях и нежелательные — в других. «Темные стороны души» метода POST компенсируются достоинствами метода GET, и наоборот. В каждом конкретном случае разработчику нужно принимать одно решение из многих, неизбежно отказываясь от одних возможностей в пользу других, причаливать к тому или иному берегу. Или метаться между двух огней, искать компромиссы — такое тоже не редкость…
Метод GET привлекает разработчиков своей простотой — все переданные таким способом параметры прочесть легче, нежели данные, отправленные при помощи метода POST. Очевидные плюсы есть и для пользователя — все параметры на виду, и более-менее искушенный серфер может править их значения прямо в адресной строке браузера, во всей полноте ощущая свободу «неофициальной» навигации.
Но, как известно, палка о двух концах… Длинные URL с обилием спецсимволов трудно запоминаются и порой даже вызывают недоверие у не слишком подкованных пользователей. К тому же, излишняя раскрепощенность посетителей не всегда бывает в интересах разработчика — например, она совершенно неприемлема в тех случаях, когда требуется, чтобы некоторые из параметров принимали только фиксированные значения из строго определенного списка. А уж если речь идет об информации конфиденциального характера, то тем более весьма нежелательно, чтобы такие данные выставлялись на всеобщее обозрение. В этом смысле метод POST, конечно, несколько безопаснее.
Главный недостаток метода GET — ограниченная протяженность строки пользовательских параметров. Максимальная длина URL не оговаривается спецификациями протокола HTTP, но на практике она в каждом конкретном случае зависит как от версии браузера, так и от настроек сервера — так или иначе, в любом случае растянуть пользовательские данные от Владивостока до Бреста не получится. Я обычно ориентируюсь на «потолок» порядка килобайта.
Метод POST, напротив, не налагает никаких ограничений на объем передаваемых данных, и именно в этом заключается основное его преимущество перед GET. К сожалению, почти все достоинства метода POST на этом и заканчиваются.
Органический недостаток метода POST — невозможность поставить прямую гипертекстовую ссылку на страницу, сгенерированную на основе конкретных значений параметров. Отсюда вытекает невозможность индексирования подобных динамических отчетов поисковыми системами.
Еще один существенный недостаток заключается в нарушении логики работы кнопки Назад — самого популярного элемента пользовательского интерфейса браузера. Вернуться на страницу, сгенерированную при помощи метода POST, после перехода с нее куда бы то ни было еще, довольно трудно. Internet Explorer, например, выдаст сообщение: «Внимание: страница устарела» с требованием нажать на кнопку Обновить, если намерения пользователя вновь просмотреть злополучную страницу все же сколько-либо серьезны.
В ряде браузеров возникают трудности при сохранении веб-страниц, сгенерированных динамически с применением метода POST, для локального просмотра. Отмечаются также проблемы с распечаткой подобных документов.
В общем и целом, подводя итог, скажем, что с позиций заботы о пользователях метод POST — мягко говоря, не самый лучший выбор. Так что при проектировании сложных многошаговых приложений (например, интернет-магазинов) метод POST нужно стараться использовать только там, где требуется передача действительно больших объемов информации. При этом желательно, чтобы логика работы приложения строилась таким образом, что страницы, генерируемые на основе данных, отправляемых методом POST, не требовали бы возврата к себе.


© 2008-2018 ОптимизацияВебСайтов.ру


Любое использование текстового и графического контента сайта без активной ссылки на источник не доскается.