Loading AI tools
В программировании POST — один из многих методов запроса, в целях поддерживаемых HTTP протоколом, используемым во Всемирной паутине. Метод запроса POST предназначен для направления запроса, при котором веб-сервер принимает данные, заключённые в тело сообщения, для хранения. Он часто используется для загрузки файла или представления заполненной веб-формы.
В отличие от него, метод HTTP GET предназначен для получения информации от сервера. В рамках GET-запроса некоторые данные могут быть переданы в строке запроса URI, указывающие, например, условия поиска, диапазоны дат, или другую информацию, определяющую запрос. В рамках POST запроса произвольное количество данных любого типа может быть отправлено на сервер в теле сообщения запроса. Поля заголовка в POST-запросе обычно указывают на тип содержимого.
 | В разделе не хватает ссылок на источники (см. рекомендации по поиску). |
Всемирная паутина и протокол HTTP основаны на ряде методов запросов или «глаголов», включая POST и GET, а также PUT, DELETE и ряд других. Веб-браузеры обычно используют только GET и POST, но REST онлайн-приложения заставляют использовать и многие другие. Метод POST предназначен для отправки представления новой сущности на сервер, так что она будет храниться как подресурс ресурса, идентифицированного URI. Например, для URI http://example.com/customers (недоступная+ссылка) с помощью POST запросов можно было бы представлять новых клиентов, каждый из которых содержал бы имя, адрес, контактные данные и тому подобное. Разработчики сайтов отошли от этой концепции по двум причинам. Во-первых, нет никаких технических причин для URI текстуально описывать подчинённые веб-ресурсы, на которых будут сохранены данные, посланные методом POST. В самом деле, последняя часть URI более вероятно опишет страницу обработки веб-приложения и её технологию, например http://example.com/applicationform.php (недоступная+ссылка). Во-вторых, учитывая естественное ограничение большинства веб-браузеров использовать только методы GET или POST, разработчики понимали необходимость добавления дополнительных возможностей в метод POST, включая изменение существующих записей и их удаление.
Попытки исправить первый недостаток начались ещё в 1998 году. Фреймворки веб-приложений, такие как Ruby on Rails и другие помогали разработчикам предоставлять своим пользователям человекопонятные URL. Что касается второго пункта, можно написать клиентские сценарии или автономные приложения, которые будут использовать другие методы HTTP, преобразовывая их затем в метод POST.
То есть нельзя сказать, что каждая веб-форма должна содержать метод POST в открывающем теге. Многие формы используются более точно для получения информации с сервера, без изменения основных баз данных. Для таких форм поиска идеально подходит метод GET.
Бывают случаи, когда HTTP GET менее подходит даже для получения данных. Примером является ситуация, когда большое количество данных должно быть записано в URL. Браузеры и веб-серверы могут иметь ограничения на длину URL, которые они обрабатывают без усечения или ошибки. URL-кодирование зарезервированных символов в адресе и строке запроса может значительно увеличить длину, в то время как HTTP-сервер Apache может обрабатывать до 4000 символов (8190 байт) в URL[1], Microsoft Internet Explorer ограничивает длину любого URL 2048 символами[источник не указан 1753 дня].
Равным образом, HTTP GET не должен использоваться для конфиденциальной информации, такой как имена пользователей и пароли, которые должны быть представлены вместе с другими данными для завершения запроса. Даже при использовании HTTPS, предотвращающим перехват данных при передаче, истории браузера и журналы веб-сервера, вероятно, содержат полные URL в виде открытого текста, которые могут быть найдены, если система будет взломана. В этих случаях используется HTTP POST.
Когда веб-браузер отправляет POST-запрос с элементами веб-формы, по умолчанию интернет-тип данных медиа — application/x-www-form-urlencoded. Это формат для кодирования пар ключ-значение с возможностью дублирования ключей. Каждая пара ключ-значение отделяется символом &, ключ отделён от значения символом =. В ключах и значениях пробелы заменяются на знак +, и затем, используя URL-кодирование, заменяются все не буквенно-цифровые символы.
Например,
Name: Jonathan Doe Age: 23 Formula: a + b == 13 %!
будет закодировано как
Name=Jonathan+Doe&Age=23&Formula=a+%2B+b+%3D%3D+13+%25%21
Начиная с HTML 4.0, формы могут также представить данные в multipart/form, как определено в RFC 2388 (см. также RFC 1867 для более ранней экспериментальной версии определённой как расширение HTML 2.0 и упоминаемой в HTML 3.2). Частный случай метода POST при обращении на ту же страницу, которой принадлежит форма, называется обратной передачей.
В RFC 2616 метод POST должен быть использован для любого контекста, в котором запрос не идемпотентен: то есть, он вызывает изменение состояния сервера каждый раз при выполнении, такие как отправка комментария к сообщению в блоге или интернет-голосование. На практике, метод GET часто зарезервирован, не просто для идемпотентных действий, но и для нульпотентных, то есть без побочных эффектов (в отличие от «без побочных эффектов при втором и последующих запросах» как с идемпотентными операциями). По этой причине сайты поисковых систем, таких как индексаторы поисковых систем обычно используют исключительно метод GET, для предотвращения каких-либо действий при автоматизированных запросах.
Тем не менее, есть причины почему POST используется даже для идемпотентных запросов, особенно если запрос использует не-ASCII символы или очень длинный, из-за ограничений на URL — строка запроса GET-метода может быть очень длинной, особенно при использовании URL-кодирования.
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
