HTTP определяет различные способы взаимодействия с сервером, и существует 4 основных метода: GET, POST, PUT и DELETE. Полное название URL — это дескриптор ресурса, его можно представить так: URL-адрес, который используется для описания ресурса в сети, а GET, POST, PUT, DELETE в HTTP соответствует четырём операциям: проверке, изменению, добавлению и удалению этого ресурса. На этом этапе у вас должно быть общее понимание: GET обычно используется для получения и запроса информации о ресурсах, а POST — для обновления информации.
1. Согласно спецификации HTTP, GET используется для поиска информации и должен быть безопасным и идемпотентным.
(1). Так называемая безопасность означает, что операция используется для получения информации, а не для её модификации. Другими словами, запросы на GET обычно не должны иметь побочных эффектов. То есть он получает только информацию о ресурсах, как и запросы к базе данных, и не изменяет, не добавляет данные и не влияет на состояние ресурса.
* Примечание: Здесь понятие «безопасность» относится только к неизменённой информации.
(2). Идемпотентный означает, что несколько запросов на один и тот же URL должны возвращать один и тот же результат.
Однако на практике эти два правила не столь строгие. Примеры цитирования чужих статей: например, главная страница новостного сайта постоянно обновляется. Хотя второй запрос возвращает другую партию новостей, операция всё равно считается безопасной и идемпотентной, потому что всегда возвращает актуальные новости. В принципе, если цель — чтобы пользователь открывал ссылку, он мог быть уверен, что ресурс не был изменён с его точки зрения.
2. Согласно спецификации HTTP, POST представляет собой запрос, который может изменять ресурс на сервере. Продолжая цитировать приведённый выше пример: Still news. Возьмём сайт в качестве примера: читатели должны оставлять свои собственные комментарии к новостям, потому что ресурсы сайта меняются после публикации комментария или изменения ресурсов.
Вышеописанное примерно рассматривает некоторые принципы GET и POST в спецификации HTTP. Однако многие люди не следуют спецификации HTTP при непосредственном выполнении, что может привести к множеству причин этой проблемы, например:
1. Многие используют GET для обновления ресурсов, потому что им нужно зайти в FORM, чтобы использовать POST, что может быть немного проблемным.
2. Операция добавления, удаления, изменения и проверки ресурсов может быть выполнена через GET/POST без необходимости использовать PUT и DELETE.
3. Другая причина в том, что ранние дизайнеры фреймворков Web MVC сознательно не рассматривали и не проектировали URL как абстрактные ресурсы, поэтому серьёзная проблема заключается в том, что традиционный фреймворк Web MVC фактически поддерживает только два метода HTTP — GET и POST, но не поддерживает методы PUT и DELETE.
* Краткое объяснение MVC: MVC изначально существовал в настольной программе, M — модель данных, V — пользовательский интерфейс, C — контроллер. Цель использования MVC — разделить код реализации M и V, чтобы одна и та же программа могла использовать разные представления.
Вышеуказанные 3 пункта обычно описывают старый стиль (без строгого соблюдения HTTP-спецификации), а с развитием архитектуры появился REST (Representational State Transfer) — новый стиль, поддерживающий спецификацию HTTP.
После обсуждения основной проблемы давайте рассмотрим разницу между GET и POST по поверхностному феномену:
1. Данные запроса GET будут прикреплены к URL (то есть данные размещены в заголовке протокола HTTP), а ? Разделите URL и передайте данные, и параметры соединяются с помощью &, например: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Если данные — английские буквы/цифры, отправьте их как есть, если это пробел — конвертируйте в +, если китайские/другие символы, затем напрямую зашифруйте строку с помощью BASE64, чтобы получить образец, например: %E4%BD%A0%E5%A5%BD, где XX в %XX — это ASCII, представленный символом в шестнадцатеричном.
POST помещает отправленные данные в тело пакета HTTP-пакета.
2. «Максимальный объем данных, передаваемых методом GET, может составлять только 1024 байта, теоретически ограничений на POST нет, и можно передавать большое количество данных — до 80 КБ в IIS4 и 100 КБ в IIS5??!
Приведённое выше предложение перенаправлено с других статей, на самом деле неправильно и неточно говорить так:
(1). Прежде всего, «данные, поданные методом GET, могут быть максимум 1024 байта», поскольку GET отправляет данные через URL, и объём данных, которые может быть отправлен GET, напрямую связан с длиной URL. На самом деле, для URL нет верхнего предела параметров, и спецификация протокола HTTP не ограничивает длину URL. Это ограничение — это ограничение, наложенное конкретным браузером и сервером. Ограничение по длине URL в IE составляет 2083 байта (2K+35). Для других браузеров, таких как Netscape, Firefox и др., теоретического ограничения по длине нет, и он зависит от поддержки операционной системы.
Обратите внимание, что это ограничивает всю длину URL, а не только длину данных параметров. [См. ссылку 5]
(2). Теоретически у POST нет ограничения по размеру, и спецификация протокола HTTP не имеет ограничения по размеру, и неточно утверждать, что «существует ограничение размера 80K/100K для данных POST», нет ограничения для данных POST, и именно вычислительная мощность обработчика сервера играет ограничивающую роль.
Для ASP-программ объект Request имеет ограничение длины данных в 100K при обработке каждого поля формы. Но с Request.BinaryRead такого ограничения нет.
Кроме того, для IIS 6.0 Microsoft ужесточила ограничения по соображениям безопасности. Также нужно обратить внимание на:
1). IIS 6.0 по умолчанию содержит максимум 200 КБ данных ASP POST, а лимит — 100 КБ на поле формы.
2). Размер файлов для загрузки IIS 6.0 по умолчанию составляет 4 МБ.
3). IIS 6.0 по умолчанию имеет максимальный заголовок запроса 16 КБ.
Эти ограничения не были доступны до IIS 6.0. [См. ссылку 5]
Так что вышеуказанные 80K и 100K могут быть просто значениями по умолчанию (примечание: я ещё не подтвердил параметры IIS4 и IIS5), но вы вполне можете настроить их сами. Поскольку значения по умолчанию для этих параметров различаются в каждой версии IIS, пожалуйста, обратитесь к соответствующему конфигурационному документу IIS для подробностей.
3. В ASP сервер использует Request.QueryString для получения параметра запроса GET и Request.Form для получения параметра запроса POST. В JSP используйте request.getParameter(\"XXXX\") для его получения, хотя в jsp также есть метод request.getQueryString(), но он сложнее в использовании, например: отправьте test.jsp?name=hyddd&password=hyddd и используйте request.getQueryString() для получения :name= hyddd&password=hyddd。 В PHP вы можете использовать $_GET и $_POST для получения данных из GET и POST соответственно, а $_REQUEST может получить данные как из GET, так и POST. Стоит отметить, что использование запроса в JSP и _REQUEST долларов в PHP имеют скрытые риски, что будет изложено в следующей статье.
4.POST безопаснее, чем GET. Примечание: упомянутая здесь безопасность отличается от понятия «безопасность», упомянутой в GET выше. Например, если вы отправляете данные через GET, ваше имя пользователя и пароль будут отображаться в открытом виде на URL, потому что (1) страница входа может быть кэширована браузером, (2) другие будут видеть историю браузера, чтобы получить ваш аккаунт и пароль Атака на подделку.
В итоге, Get — это запрос на запрос данных с сервера, а Post — запрос на отправку данных на сервер, а в FORM Method по умолчанию установлен на «GET», по сути, GET и POST — это просто разные механизмы отправки, а не один из них отправляет и не отправляет!
|
Опубликовано 06.12.2014 10:54:55
|
|
|
Опубликовано 07.12.2014 17:24:18
