ДОБЕРИТЕСЬ по сравнению с POST, он действительно действительно имеет значение?

Technically, no. All GET does is post the stuff in the first line of the HTTP request, and POST posts stuff in the body.

However, how the "web infrastructure" treats the differences makes a world of difference. We could write a whole book about it. However, I'll give you some "best practises":

Use "POST" for when your HTTP request would change something "concrete" inside the web server. Ie, you're editing a page, making a new record, and so on. POSTS are less likely to be cached, or treated as something that's "repeatable without side-effects"

Use "GET" for when you want to "look at an object". Now, such a look might change something "behind the scenes" in terms of caching or record keeping, but it shouldn't change anything "substantial". Ie, I could repeat my GET over and over and nothing bad would happen, except for inflated hit counts. GETs should be easily bookmarkable, so a user can go back to that same object later on.

The parameters to the GET (the stuff after the ?, traditionally) should be considered "attributes to the view" or "what to view" and so on. Again, it shouldn't actually change anything: use POST for that.

And, a final word, when you POST something (for example, you're creating a new comment), have the processing for the post issue a 302 to "redirect" the user to a new URL that views that object. Ie, a POST processes the information, then redirects the browser to a GET statement to view the new state. Displaying information as a result of a POST can also cause problems. Doing the redirection is often used, and makes things work better.

Yes, it does matter. GET and POST are quite different, really.

You are right in that normally, GET is for "getting" data from the server and displaying a page, while POST is for "posting" data back to the server. Internally, your scripts get the same data whether it's GET or POST, so no, the server doesn't really care.

The main difference is GET parameters are specified in URLs, while POST is not. This is why POST is used for signup and login forms - you don't want your password in a URL. Similarly, if you're viewing different pages or displaying a specific view of some data, you normally want a unique URL.

Be aware that browsers may cache GET requests but will generally not cache POST requests.

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

The server usually doesn't care. But it's mostly for following good practices, as you mentioned. The client side also matter - as mentioned you cannot bookmark a POST'd page usually, and some browsers have limits on the length of the URL for really long GET queries.

The server technically couldn't care one way or the other about what kind of request it receives. It will blindly execute any request coming across the wire.

Which is the problem. If you have an action that destroys or modifies data in a GET action, Google will tear your site up as it crawls through indexing.

GET has data limit restrictions based on the sending browser:

The spec for URL length does not dictate a minimum or maximum URL length, but implementation varies by browser. On Windows: Opera supports ~4050 characters, IE 4.0+ supports exactly 2083 characters, Netscape 3 -> 4.78 support up to 8192 characters before causing errors on shut-down, and Netscape 6 supports ~2000 before causing errors on start-up

"Use GET if: The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup)."

"Use POST if: The interaction is more like an order, or the interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or the user be held accountable for the results of the interaction."

source

Это зависит от программного обеспечения на стороне сервера. Некоторые библиотеки, такие как CGI.pm в Perl, по умолчанию обрабатывают и то, и другое. Но бывают ситуации, когда вам более или менее необходимо использовать POST вместо GET, по крайней мере, для отправки данных на сервер. Большие объемы данных (где соответствующий URL-адрес GET стал бы слишком длинным), двоичные данные (чтобы избежать множества проблем с кодированием / декодированием), составные файлы, не проанализированные заголовки (для непрерывных обновлений до стиля AJAX ...) и тому подобное. .

If you use a GET request to alter back-end state, you run the risk of bad things happening if a webcrawler of some kind traverses your site. Back when wikis first became popular, there were horror stories of whole sites being deleted because the "delete page" function was implemented as a GET request, with disastrous results when the Googlebot came knocking...

According to the HTTP RFC, GET should not have any side-effects, while POST may have side-effects.

The most basic example of this is that GET is not appropriate for anything like a purchase-transaction or posting an article to a blog, while POST is appropriate for actions-that-have-consequences.

By the RFC, you can hold a user responsible for actions done by POST (such as a purchase), but not for GET actions. 'Bots always use GET for this reason.

From the RFC 2616, 9.1.1:

9.1.1 Safe Methods

Implementors should be aware that the программное обеспечение представляет пользователя в
их взаимодействие через Интернет, и должны быть осторожны, чтобы позволить пользователь должен быть в курсе любых действий, которые он может занять, у которого может быть
неожиданное значение для себя или др.

В частности, конвенция Было установлено, что GET и
HEAD методы НЕ ДОЛЖНЫ иметь значение совершения действия
кроме поиска. Эти методы следует считать "безопасным". это позволяет пользовательским агентам представлять другие методы, такие как POST, PUT и DELETE особым образом, чтобы пользователь осведомлен о том, что возможно небезопасное действие запрошено.

Естественно, невозможно убедитесь, что сервер не
вызывать побочные эффекты в результате выполнение запроса GET; на самом деле, некоторые динамические ресурсы считают, что feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

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

Даже если вашему серверу все равно (а это маловероятно), между вашим клиентом и сервером могут быть промежуточные агенты, и все они ожидают этого. Например, прокси-серверы для кэширования данных у вашего интернет-провайдера или других поставщиков для повышения производительности. Те же ожидания верны и для ускорителей, например, для плагина предварительной загрузки для вашего браузера.

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

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

Это очень простой подход. Для получения дополнительной информации вы можете изучить книгу Руби и Ричардсона «RESTful Web Services» (издательство O'Reilly).

Чтобы быстро разобраться в теме REST, прочтите этот пост:

http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx

Самое смешное, люди спорят о достоинствах PUT v POST. Проблема GET v POST решена и всегда решалась очень хорошо. Игнорируйте это на свой страх и риск.

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

Это очень простой подход. Для получения дополнительной информации вы можете изучить книгу Руби и Ричардсона «RESTful Web Services» (издательство O'Reilly).

Чтобы быстро разобраться в теме REST, прочтите этот пост:

http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx

Самое смешное, люди спорят о достоинствах PUT v POST. Проблема GET v POST решена и всегда решалась очень хорошо. Игнорируйте это на свой страх и риск.

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

Это очень простой подход. Для получения дополнительной информации вы можете изучить книгу Руби и Ричардсона «RESTful Web Services» (издательство O'Reilly).

Чтобы быстро разобраться в теме REST, рассмотрите этот пост:

http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx

Самое смешное, что большинство люди спорят о достоинствах PUT v POST. Проблема GET v POST решена и всегда решалась очень хорошо. Игнорируйте это на свой страх и риск.

я не хочу, чтобы счета были списаны несколько раз из-за сетевых ошибок и т. д.)

Это очень простой подход. Для получения дополнительной информации вы можете изучить книгу Руби и Ричардсона «RESTful Web Services» (издательство O'Reilly).

Чтобы быстро разобраться в теме REST, рассмотрите этот пост:

http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx

Самое смешное, что большинство люди спорят о достоинствах PUT v POST. Проблема GET v POST решена и всегда решалась очень хорошо. Игнорируйте это на свой страх и риск.

я не хочу, чтобы счета были списаны несколько раз из-за сетевых ошибок и т. д.)

Это очень простой подход. Для получения дополнительной информации вы можете изучить книгу Руби и Ричардсона «RESTful Web Services» (издательство O'Reilly).

Чтобы быстро разобраться в теме REST, рассмотрите этот пост:

http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx

Самое смешное, что большинство люди спорят о достоинствах PUT v POST. Проблема GET v POST решена и всегда решалась очень хорошо. Игнорируйте это на свой страх и риск.

com / weblog / 2008/08/17 / ExplainingRESTToDamienKatz.aspx

Забавно то, что большинство людей спорят о достоинствах PUT и POST. Проблема GET v POST решена и всегда решалась очень хорошо. Игнорируйте это на свой страх и риск.

com / weblog / 2008/08/17 / ExplainingRESTToDamienKatz.aspx

Забавно то, что большинство людей спорят о достоинствах PUT и POST. Проблема GET v POST решена и всегда решалась очень хорошо. Игнорируйте это на свой страх и риск.

You be aware of a few subtle security differences. See my question

GET versus POST in terms of security?

Essentially the important thing to remember is that GET will go into the browser history and will be transmitted through proxies in plain text, so you don't want any sensitive information, like a password in a GET.

Obvious maybe, but worth mentioning.

Нет, они не должны, за исключением ответа @ jbruce2112, а для загрузки файлов требуется POST.

Должен ли пользователь сделать закладку на получившуюся страницу? Еще одна вещь, о которой стоит подумать, это то, что некоторые браузеры / серверы неправильно ограничивают длину GET URI.

Edit: исправлено примечание об ограничении длины char - спасибо ars!

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

GET имеет ограничения на стороне браузера. Например, некоторые браузеры ограничивают длину GET-запросов.

Это происходит, если поисковая система просматривает страницу, поскольку они будут делать запросы GET, но не POST. Предположим, у вас есть ссылка на вашей странице:

http://www.example.com/items.aspx?id=5&mode=delete

Без какой-либо проверки авторизации, выполняемой перед удалением, возможно, что робот Googlebot сможет войти и удалить элементы с вашей страницы.