Почему должен я данные POST, а не ДОБИРАТЬСЯ?
Я знаю, что Вы не хотите к POST форму с именем пользователя и паролем, где любой мог использовать историю для наблюдения или ситуации, где повторные действия не могут быть желаемы (обновление страницы = добавление, что объект к корзине не может быть желаем). Таким образом, у меня есть понимание, когда я могу хотеть использовать один по другому. Но у меня могло всегда быть перенаправление сервера URL после ПОЛУЧЕНИЯ для обхождения проблемы корзины, и возможно большинство моих форм будет работать превосходное с, ДОБИРАЮТСЯ.
Почему я должен использовать POST, ДОБИРАЮТСЯ? Я не понимаю преимуществ одного по другому. Я замечаю, что POST не добавляет данные к ИСТОРИИ/URL и предупредит Вас об обновлении страницы, но это - эти только два различия, о которых я знаю. Почему, поскольку разработчик мог бы я хотеть использовать один по другому?
5 ответов
Каждый HTTP-метод: POST, GET, PUT, DELETE и т. Д. Имеет собственную семантику. При выборе правильного метода важно понимать HTTP и REST , поскольку именно так должен работать HTTP и как работает основная сетевая инфраструктура.
Хорошее руководство по REST доступно здесь .Вот что говорится о методах POST и GET:
Поскольку для каждого ресурса используется один и тот же интерфейс, вы можете рассчитывать на возможность получить представление, то есть некоторую его визуализацию, с помощью GET. Поскольку семантика GET определена в спецификации, вы можете быть уверены, что при ее вызове у вас нет никаких обязательств - вот почему метод называется «безопасным». GET поддерживает очень эффективное и сложное кэширование, поэтому во многих случаях вам даже не нужно отправлять запрос на сервер. Вы также можете быть уверены, что GET является идемпотентным - если вы отправляете запрос GET и не получаете результата, вы можете не знать, не достиг ли ваш запрос места назначения или ответ потерялся на обратном пути к вам.
Гарантия идемпотентности означает, что вы можете просто отправить запрос еще раз . Идемпотентность также гарантируется для PUT (что в основном означает «обновите этот ресурс этими данными или создайте его по этому URI, если его еще нет») и для DELETE (что вы можете просто пробовать снова и снова, пока не получите результат - удаление то, чего нет, не проблема). POST, что обычно означает «создать новый ресурс», также может использоваться для вызова произвольной обработки и, таким образом, не является ни безопасным, ни идемпотентным .
Помимо прочего, GET ограничен 2K (некоторые браузеры принимают больше), и это видно в URL
Если вам нужен идемпотентный URI запроса (т.е. ответ всегда один и тот же), то используйте GET, иначе POST.
GET и POST имеют семантическое значение - GET используется для получения ресурса, а POST - для его изменения. Именно из-за семантики вы замечаете различия в реализации в вашем веб-браузере - поскольку POST якобы изменяет данные, браузер должен предупреждать перед повторной отправкой запроса/команды POST.
Весь веб работает на этой семантике. Безопасно кэшировать GET-запрос, но не POST-команду - именно так поступают кэширующие прокси. Безопасно получать ресурс несколько раз, поэтому существуют устройства предварительного поиска ссылок, которые делают именно это. Безопасно делать закладки и обновлять GET, поэтому браузеры не предупреждают об этом, и т. д. и т. п.
Тем не менее, разницы в безопасности нет - поэтому приведенный вами пример с именем пользователя и паролем не совсем точен. POST так же легко подделать или просмотреть, как и GET.
Все данные в запросе GET переносятся в URL-адресе, который имеет ограничение по размеру и также виден пользователю. Запрос POST также позволяет отправлять полезные данные.
Помимо технических отличий, есть смысл.Стандарт HTTP описывает способы, которыми различные запросы ( GET , POST , PUT , DELETE , HEAD ) предназначены для использования; например, PUT предназначен для добавления ресурса, DELETE предназначен для его удаления, а POST предназначен для его изменения. Не могли бы вы использовать запрос GET вместо PUT или DELETE ? Конечно, но следование стандартам делает намерение явным.
См. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html для получения дополнительной информации.