Когда я должен использовать методы POST и GET?

Каковы различия между методами GET и POST?

  • Это единственное различие, которое могут видеть переменные в методе GET в унифицированном указателе ресурса и в POST будь спрятанным?

Что ты (дал) преимущества, имеет один по отношению к другому?

  • Возможно говорить, что переменные, посланный путь POST они уверены?
25
задан 26.11.2016, 20:10
6 ответов

Я хочу отобразить / объяснить в форме более практический различие между методами POST's и GET'в.

Для этого мы будем использовать один <form> и для примеров мы используем эту стоимость:

"user" = "pepe" | "pass" = "cocoloco"

Формуляр с методом GET:

<form action="login.php" method="get">
    <input type="text" name="user">
    <input type="password" name="pass">
    <input type="submit" name="submit">
</form>

Если мы не включаем признак method по умолчанию послан способ GET.

С элементом HTML Anchor <a> возможно посылать также (и только) из-за способа GET:

<a href="/libros.php?autor=pepe&libro=cocoloco">Un libro interesante</a>

Формуляр с методом POST:

<form action="login.php" method="post">
    <input type="text" name="user">
    <input type="password" name="pass">
    <input type="submit" name="submit">
</form>

Давайте видеть, как относится каждый к запросам:

Заголовок запроса / Request header method="get":

  • GET /login.php?user=pepe&pass=cocoloco&submit=Enviar HTTP/1.1
  • Host: example.com

Вид URL: example.com/login.php?user=pepe&pass=cocoloco&submit=Enviar

Заголовок запроса / Request header method="post":

  • POST /login.php HTTP/1.1
  • Host: example.com
  • Content-Length: 37
  • Content-Type: application/x-www-form-urlencoded

Вид URL: example.com/login.php

Из-за которого мы не видим в method="post" параметры / стоимость?

Для этого есть, что знание, что HTTP Request (запрос HTTP) будь сформирован несколькими компонентами, мы будем обращать внимание только, которые он интересует нас прямо сейчас:

Различие в GET и POST дело в том, что GET у него нет компонента Response Body (Тело), поэтому сам включи GET параметры / стоимость в URI (Адрес) и следовательно видимый для всех.

В случае POST, мы знаем сейчас, что он приносит контент сообщения в Response Body (Тело).

Если мы уходим в консоль браузера (в моем случае Chrome)

Network => Name: login.php => Headers => Form Data

мы можем видеть контент тела:

user=pepe&pass=cocoloco&submit=Enviar

Content-Length: 37 он показывает нам длину контента.

Content-Type он показывает нам типы данных, которые посланы.

Если ты хочешь узнать больше различных типов данных => ИЗБАЛУЙТЕ

Сейчас они скажут какие-то:

Что хорошо! Если я использую метод POST не может видеть никто супер пароль или чувствительные данные....

Ehm... так как к сожалению НЕ! (если ты это посылаешь из-за http).

Проблема:

Атака человека в способе... (переведенный буквально с английского языка: Man-In-the-Middle Attack) - атака Посредника.

Wikipedia: Атака Посредника

Атака, в которой приобретается способность читать, вводить и изменять в волю, сообщения между двумя частями без того, чтобы ни одна из них не узнала, что ссылка между ними была нарушена.

Решение:

Если хочешь послать мягкие ты супер секретную информацию в твой сервер, ты должен использовать:

https - Протокол, уверенный в перенесении гипертекста

Сейчас они скажут:

Если он зашифрован, я могу использовать метод GET чтобы посылать чувствительные данные!

Mmmmm так как... nop!

Верный он что совсем этот encriptado, но в случае метода GET консультации остаются сохраняемыми в logs сервера и тогда, если бы он был доступным одной или другого способа.

Короткое заключение:

Используй всегда POST для чувствительных данных и SSL HTTPS... если ты хочешь быть уверен и ·!

Сравнения:

               |            GET            |           POST           |
-----------------------------------------------------------------------
Historial      | Los parámetros permanecen | Los parámetros no se     |
               | en el historial del       | guardan en el historial  |
               | navegador porque forman   | del navegador            |
               | parte de la URL           |                          |
-----------------------------------------------------------------------
Guardar en     | Es posible                | No es posible            |
Favoritos      |                           |                          |
-----------------------------------------------------------------------
Cached         | Es posible                | No es posible            |
-----------------------------------------------------------------------
Visibilidad    | Es visible para todos -   | No se muestra en la URL  |
               | se mostrará en la barra   |                          |
               | de direcciones del        |                          |
               | navegador                 |                          |
-----------------------------------------------------------------------
Usabilidad     | No se debe utilizar para  | Utilizado para enviar    |                                               
               | enviar contraseñas u otra | contraseñas u otra       |
               | información sensible      | información sensible     |
-----------------------------------------------------------------------
Comportamiento | Las solicitudes se        | El navegador suele       |
botón atrás /  | vuelven a ejecutar pero   | alertar al usuario de    |
reenviar       | no se puede volver a      | que los datos tendrán    |
               | enviar al servidor, si el | que volver a enviarse    |
               | HTML se almacena en el    |                          |
               | cache del navegador       |                          |
------------------------------------------------------------------------
Restricciones  | El límite de longitud de  | Sin restricciones        |
en la longitud | la URL suele ser de 2048  |                          |
               | caracteres, pero varía    |                          |
               | según el navegador y el   |                          |
               | servidor web              |                          |
-----------------------------------------------------------------------
Seguridad      | Es menos seguro porque    | Es más seguro ya que no  |
               | los datos enviados forman | se guarda en el          |
               | parte de la URL, por lo   | historial ni en los logs |
               | tanto, se guarda en el    | del servidor             |
               | historial del navegador y |                          |
               | en los logs del servidor  |                          |
-----------------------------------------------------------------------
Hacked         | Más fácil de hackear      | Difícil de hackear       |
-----------------------------------------------------------------------
14
ответ дан 24.11.2019, 12:30

Методы GET VS POST

Часто мы думали ошибочно об использовании GET и POST. Мы имеем, чтобы понимать, что, когда я даю клик в одной URL это GET и когда я посылаю формуляр, он POST. Мы обычно думаем, что посылая просьбы из-за метода POST данные путешествуют страховки, из-за того, что не идут как часть URL поскольку он это делает GET. Эта концепция ошибочная, это не различия между соединениями и формулярами.

Так метод GET как POST это протокол HTPP который он посылает в сервер как просьба (request) и получает ответ на вышеупомянутый запрос (response). В мой критерий, здесь находится часть путаницы на реальных целях обоих методов.

Petición HTTP

Давайте повторно определять концепции

Концепция GET он состоит в том, чтобы получать информацию о сервере. Приносить данные, которые хранятся на сервере, уже было база данных или файл в клиента. Независимо, которого для этого мы были должны посылать (request) какую-то информацию, которая будет обработана, чтобы потом возвращать ответ (response), что ожидаться, пример состоял бы в том, чтобы получать идентификатора, чтобы получать статью о базе данных.

Концепция POST взамен он состоит в том, чтобы посылать информацию с клиента paraa, что был обработан и обновил или добавил информацию на сервере, как оно было бы грузом или обновлением, если статьи. Когда мы посылаем (request) данные через формуляр, эти обработаны и потом через перенаправление, пример мы возвращаем (response) какую-то страницу с информацией.

Так GET как POST они просят ответ сервера и там, где они кажутся, что концепции равны, так как с обоими было бы возможно добиваться тех же целей. Я смог бы, хотя он не правилен, посылать из-за GET некие данные в одной URL или обновлять или вводить вышеупомянутую информацию в моей базе данных, но действительно это соответствует ему методу POST. Того же способа он мог бы просить различную страницу посредством POST и просто показывать ее как ответ, хотя это должно бы быть через вызов GET.

Вызовы из-за метода GET они могут быть cacheadas (плывущая биография), indexadas из-за поисковых служб, добавлять ссылки к нашим фаворитам или до того, чтобы перемещать одну URL заверши другого человека для того, чтобы он вводит информацию в компьютер в вышеупомянутую страницу. С методом POST однако не возможно делать это.

Обычно мы используем соединения, чтобы выполнять вызовы GET так как идея о соединении состоит в том, чтобы “просить” просто информацию (страницу) в servidor и что был возвращен как ответ. Пока мы используем формуляры, чтобы обновлять данные, как статьи, пользователи, и т.д. также в счете, чем из-за метода POST также себе может посылать больше количество данных, что из-за GET.

Случай анализа.

Давайте предполагать, что у нас была тележка покупок, с одной URL что добавил продукты к тележке покупок. Обычно, если мы делаем эту URL осталось бы нечто похожее (misitio.com/agregar_item.php?id=1). В существо вызов GET, Google мог бы индексировать эту URL и могло бы появляться в поисковой службе слово тележка. Проблема здесь, если бы посетитель выполнил эту страницу, автоматически добавила бы эту статью к тележке покупок, с чем это не идея, так как посетитель после того, как ищет тележку покупок, был бы должен входить просто в сайт и не добавлять никакой статьи, которая даже знает, который. Следовательно, мы видим, что для этого случая сколько бы мы не используем одну URL, мы были бы должны использовать призыв к методу POST, например, поскольку он это использует framework Symfony, пример:

<a onclick="f = document.createElement('form'); document.body.appendChild(f);
    f.method = 'POST'; f.action = this.href; f.submit();return false;"
    href="agregar_item.php?id=1">Añadir al carrito
</a>

То, что делает этот URL это очень просто, посредством события onclick JavaScript, создай dinámicamente формуляр, он говорит ему, что он будет POST (так как он по умолчанию был бы GET), он распределяет его URL от ссылки, пошли формуляр action form и возвратись false, чтобы не выполнять соединение в себе. Чтобы это делать с Symfony просто мы используем helper link_to добавляя выбор post=true:

<?php echo link_to('Añadir al carrito', 'agregar_item.php?id=1', 'post=true') ?>

Шрифт, где я прочитал статью: http://blog.micayael.com/2011/02/09/metodos-get-vs-post-del-http/

28
ответ дан 24.11.2019, 12:30
  • 1
    Existirá n случаи утилиты или силы, в которых для наших Веб приложений мы были бы должны использовать GET вместо POST? Я читаю и перечитываю и не вижу razó n существования в mé весь GET. – Roberto Sepúlveda Bravo 21.11.2016, 00:21
  • 2
    @RobertoSepú lvedaBravo Стоимость GET podrí an сохранять в caché и podrí чтобы быть má s rá я прошу из-за этого. – Alvaro Montoro♦ 21.11.2016, 00:26

Как добавочная информация в другие ответы, важное различие между GET и POST - количество данных, которые могут быть посланными как параметры. Использовав GET существует предел в длине унифицированного указателя ресурса (2000 caractéres) то, что переводится в пределе в количестве / длине прошлых параметров. Это ограничение не существует в случае POST, так как параметры не составляют часть унифицированного указателя ресурса и следовательно может быть посланным (теоретически) количество параметров бесконечно большой.

6
ответ дан 24.11.2019, 12:30
  • 1
    +1 из-за того, что - ú nico, о котором упоминает limitació n в tamañ или, что является одним из больших различий из двух. – Alvaro Montoro♦ 21.11.2016, 00:05
  • 2
    Эса informació n она фальшивая. Не существует нигде в протоколе HTTP, определенный RFC lí mite в длину URI, ассоциируемого с petició n GET. Эса limitació n приблизительно 2000 символов она была навязана IE, и в настоящее время он абсолютно зависимый от браузера или от Веб сервера, который может бросать ответ 413. – dwarandae 20.12.2016, 07:12
  • 3
    @dwarandae он имеет razó n. Этот lí mite - lí mite из факта má s, что limitació n в implementació n протокола. Тем не менее, мне не приходит в голову случай, в котором он был бы " razonable" использовать url этого tamañ или. – Muriano 03.04.2017, 15:43

Ответы, которые есть, - обычно правильны, но это не определение, которое больше мне нравится, так что несмотря на то, что уже есть четыре ответов сюда он идет:

Основное различие - idempotencia GET; это значит, что у GET нет эффекта в данных relacionados1. Например, если я сделаю операцию, чтобы получать фильмы кино моего города, или резюме фильма, эта просьба будет посредством GET (из-за большего количества просьб, которые он сделает, он это не затронет в какие фильмы они выставляют себя напоказ).

Это позволяет клиенту относиться к просьбам GET с большей свободой: смоги обыскивать их (или не), если он это желает, в случае когда повторяет просьбу (сделав back в браузере, например) он не нуждается в том, чтобы предупредить пользователя, и т.д.

Наоборот, POST подразумевает, что просьба может менять данные на сервере (например, что разместил ввод под мое имя в кино). Это делает, что быть нужный быть заботливее с просьбами POST, так как нужно избегать создавать просьбы, если не уверен, что то, что пользователь хочет, (знаменитое сообщение объявления, сделав back с браузером).

Способ приуменьшать проблемы POST - POST-Redirect-GET; послав формуляр POST он не возвращает тебе данные об операции но он пересылает тебя в другую страницу; с этой страницы, с GET одного пойдите сделки ты можешь видеть результаты, например число твоего ввода кино (я схватил, можешь делать back до GET, чтобы возвращать результаты, не делая POST снова).

Конечно, это на уровне стандарта, на уровне осуществления ты можешь делать услугу GET, которая делала бы изменения в данных о сервере, но если потом у тебя есть проблемы, когда пользователи это используют, это будет твоя ответственность из-за того, что сломает протокол.


1-ым разы является что-то более сложное, например поиски в Google - GET и в принципе делать поиски не изменяет полученный результат, но также хранит поиски, чтобы делать статистику и делать изменения в подсказках, рекламе, и т.д.

Он продолжил бы считаться GET, потому что то, что пользователь ищет (результаты), не оказывается поврежденным.

6
ответ дан 24.11.2019, 12:30
  • 1
    Я не заканчиваю понимать это, чего у GET нет эффекта в связанных данных. Ты говоришь, что он на уровне está ndar, ¿ ты можешь añ adir какая-то ссылка на этот está ndar? – Alvaro Montoro♦ 21.11.2016, 00:16
  • 2
    @AlvaroMontoro дело не в том, что у GET нет эффекта, дело в том, что у не должно быть это . Если у тебя есть operació n, что вызвал эффект в данных (например, формуляре, чтобы менять descripció n pelí cula), deberí схвати осуществлять это как POST. operació n, что не вызвал эффект (консультировать descripció n pelí cula) возможно помогать посредством GET (podrí в посредством POST, но tendrí в недостатки, наверху упомянутые, перейдя с одного сайта на другой, и т.д.) – SJuan76 21.11.2016, 00:18
  • 3
    Если ты это не делаешь así ты ломаешь с semá ntica (то, что он значит) каждый mé совсем и клиенты, которые присоединяются в эти услуги, могут делать это игнорируя проблемы, которые они вызывают. В конце концов GET и POST не má s, что поле заголовка petició n HTTP, различие - звук, отнесенный просьбы segú n это поле. – SJuan76 21.11.2016, 00:20
  • 4
    Гениальный. Спасибо :) – Alvaro Montoro♦ 21.11.2016, 00:21

помимо которых ты комментируешь, и у каждой есть ее собственная семантика использования. В реальной жизни, каждый манипулирует ими более или менее как заблагорассудится.

  • GET-> Получает ресурс nevagador. Адрес ресурса идет в просьбе (отсюда видимые параметры). Контент проходит по кэш-памяти браузера.
  • POST-> Посылает данные в сервер. Сервер будет знать, что делать с ними и обработает их, как он был соответствующим (отсюда невидимые параметры. Это не параметры, это данные, которых нужно хранить в ресурсе). Он должен бы быть использованным для создания новых ресурсов, в которые сервер распределит им адрес. Они не проходят по кэш-памяти клиента.
  • УДАР В ЛУНКУ-> Посылает ресурс в точное положение на сервер. Это вид обратного GET. Видимые параметры (как в GET).
5
ответ дан 24.11.2019, 12:30

Метод GET используется для того, чтобы делать себе вызовы HTTP. Он используется для того, чтобы получать данные о сервере. Могут быть посланными параметры в сервер в унифицированном указателе ресурса вызова формы: http://tudominio.com?bar=foo&baz=foo, где бар и baz - параметры и foo стоимость в обоих случаях. На уровень сообщения одинокий HTTP посылает себе заголовок. Тело сообщения HTTP идет пустота.

Метод POST используется для того, чтобы посылать информацию в сервер. В отличие от GET пошли информацию о формуляре, что posteas в теле сообщения HTTP.

2
ответ дан 24.11.2019, 12:30

Я дам тебе объяснение, видное с другого подхода

Технически ты можешь использовать их безразлично, сохраняться информация, сделав вызов GET, или которая быть должен консультировать информацию о сервере, когда HTTP делать вызов POST. в конечная, - протокол коммуникации и не приложения, так что HTTP, если тебя не ограничивает использование, которое ты даешь ему.

Однако использование, что мы должны давать ему протоколу этот normado по разуму, и он состоит в том, что HTTP сделан, чтобы мочь сообщать серверы и клиентов безразлично платформы (platform agnostic), в контексте взаимосвязи, на котором в собранный целая технологическая инфраструктура, устанавливать эту процедуру облегчает взаимосвязь между частями, позволяет тебе повторно использовать уже существующую технологию, он облегчает тебе использование API's, выставленных из-за третьих, или использовать frameworks/librerias, чтобы мочь тратить услуги третьих или выставлять твои.

Технические детали размера просьбы, которую ты должен посылать в сервер, использовав тот или иной метод, не являются такими значимыми, разработав backend, ты должен думать, что ты выставляешь ресурсы, и эти ресурсы будут соглашены из-за третьих или из-за твоих собственных приложений-клиентов, в normar, что методы, использовать, чтобы читать информацию GET (навигацию), создавать (POST), изменять (UPDATE), удалять (DELETE), OPTIONS, HEAD и т.д. эти давая большую экспрессивность твоему API использовать ее становится более натуральным, ты можешь повторно использовать tecnológia существующий, как frameworks, что помогают тебе производить характерный код, чтобы выставлять твои услуги, этот произведенный код использует методы (GET, POST и друзья), чтобы выставлять твой API. Ты можешь изменять это поведение, так как, как я упомянул о тебе технически, ты не имеешь restricciónes, но если ты вытекаешь из нормы (стандарта) тогда остаешься в твою удачу.

Ты должен считать, что также этот normado концепции safe и idempotencia для различных методов например GET - safe и idempotente, но POST не ни safe ни idempotente, если ты не используешь методы как норму тогда, как ты влез бы safe и idempotencia в твоем API? ты был бы должен определять, что он safe и idempotencia в твоем API, все книжные магазины клиент были разработаны принимая все эти концепции и standards, и если ты вытекаешь из нормы, как я упомянул о тебе тогда, ты остаешься в твою удачу, если снопы это ты должен parchear твой API для того, чтобы твоя процедура приспособилась ко всей инфраструктуре, которая уже у нас есть теперь на HTTP.

2
ответ дан 03.12.2019, 19:01

Теги

Похожие вопросы