Из того, что я могу собрать, есть три категории:
GET и используйте POSTPOST и используйте GETПравильно ли я предполагаю эти три случая? Если да, то каковы некоторые примеры из каждого случая?
Используйте POST для деструктивных действий, таких как создание (я знаю об иронии), редактирование и удаление, потому что вы не можете нажать действие POST в адресной строке вашего браузера. Используйте GET если это безопасно, чтобы позволить человеку вызвать действие. Таким образом, URL-адрес:
http://myblog.org/admin/posts/delete/357
Должен привести вас на страницу подтверждения, а не просто удалить элемент. Так легче избежать несчастных случаев.
POST также более безопасен, чем GET, потому что вы не вставляете информацию в URL-адрес. И поэтому использование GET как method для HTML-формы, которая собирает пароль или другую конфиденциальную информацию, не самая лучшая идея.
Последнее замечание: POST может передавать больший объем информации, чем GET. "POST" не имеет ограничений по размеру для передаваемых данных, а "GET" ограничен 2048 символами.
Вкратце
GET для safe and idempotent запросовPOST для neither safe nor idempotent запросовПодробнее Для каждого есть подходящее место. Даже если вы не следуете принципам RESTful, многое можно получить, узнав о REST и о том, как работает ориентированный на ресурсы подход.
ОперацияПриложение RESTful будет
use GETsдля операций, которые являются какsafe and idempotent.
A safe - это операция, которая запрашивает not change the data.
Операция idempotent - это та, в которой результат будет be the same независимо от того, сколько раз вы его запрашиваете.
Понятно, что, поскольку GET используются для безопасной работы, они автоматически также идемпотентны. Обычно GET используется для извлечения ресурса (например, вопрос и связанные с ним ответы на переполнение стека) или сбор ресурсов.
Приложение RESTful будет использовать
PUTsдля операций, которыеnot safe but idempotent.
Я знаю, что вопрос был о GET и POST, но я вернусь к POST через секунду.
Обычно для редактирования ресурса используется PUT (например, редактирование вопроса или ответ на переполнение стека).
A
POSTбудет использоваться для любой операции, которая равнаneither safe or idempotent.
Обычно POST будет использоваться для создания нового ресурса, например, для создания нового запроса SO (хотя в некоторых проектах для этого также будет использоваться PUT).
Если вы дважды запускаете POST, вы создадите два новых вопроса.
Там также операция DELETE, но я предполагаю, что могу оставить ее там:)
Обсуждение
В практическом плане современные веб-браузеры, как правило, надежно поддерживают GET и POST (вы можете выполнять все эти операции с помощью javascript-вызовов, но с точки зрения ввода данных в формы и нажатия кнопки submit вы обычно получаете два варианта). В приложении RESTful POST часто задерживается для предоставления вызовов PUT и DELETE.
Но даже если вы не следуете принципам RESTful, полезно придумать с помощью GET для получения/просмотра информации и POST для создания/редактирования информации.
Вы не должны использовать GET для операции, которая изменяет данные. Если поисковая система сканирует ссылку на ваш злой op или закладки клиента, это может вызвать большие проблемы.
Используйте GET, если вы не возражаете, чтобы повторяющийся запрос (то есть он не меняет состояние).
Используйте POST, если операция действительно меняет состояние системы.
GET: обычно используется для отправленных поисковых запросов или любого запроса, в котором вы хотите, чтобы пользователь мог снова поднять точную страницу.
Преимущества GET:
Недостатки GET:
POST: используется для более высоких запросов безопасности, где данные могут использоваться для изменения базы данных или страницы, которую вы не хотите, чтобы кто-то закладок.
Преимущества POST:
Недостатки POST:
Непосредственно из Протокол передачи гипертекста - HTTP/1.1:
9.3 GET
Метод GET означает получение любой информации (в форме объекта), идентифицируемой Request-URI. Если Request-URI ссылается на процесс создания данных, то полученные данные должны быть возвращены в качестве объекта в ответе, а не в исходном тексте процесса, если только этот текст не является результатом процесса.
Семантика метода GET изменяется на "условное GET", если сообщение запроса включает в себя поле If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match или If-Range, Условный метод GET запрашивает передачу объекта только при обстоятельствах, описанных условным полем заголовков. Условный метод GET предназначен для уменьшения ненужного использования сети, позволяя обновлять кэшированные объекты, не требуя множественных запросов или передачи данных, уже находящихся у клиента.
Семантика метода GET изменяется на "частичное GET", если сообщение запроса включает поле заголовка Range. Частичные запросы GET передают только часть объекта, как описано в разделе 14.35. Частичный метод GET предназначен для уменьшения ненужного использования сети, позволяя завершить частично восстановленные объекты без передачи данных, уже находящихся у клиента.
Ответ на запрос GET можно кэшировать тогда и только тогда, когда он отвечает требованиям кэширования HTTP, описанным в разделе 13.
См. раздел 15.1.3 для соображений безопасности при использовании для форм.
9.5 POST
Метод POST используется для запроса, чтобы исходный сервер принял объект, заключенный в запрос в качестве нового подчиненного ресурса идентифицированных Request-URI в строке запроса. POST разработан чтобы обеспечить единообразный метод для покрытия следующих функций:
Аннотация существующих ресурсов;
Размещение сообщения на доске объявлений, в новостной группе, в списке рассылки, или аналогичная группа статей;
Предоставление блока данных, например, результат подачи формы, к процессу обработки данных;
Расширение базы данных с помощью операции добавления.
Фактическая функция, выполняемая методом POST, определяется сервер и обычно зависит от Request-URI. Опубликованная организация подчиняется этому URI так же, как файл подчинен в каталог, содержащий его, новостная статья подчинена группу новостей, на которую он отправлен, или запись подчинена базы данных.
Действие, выполняемое методом POST, может не привести к ресурс, который может быть идентифицирован с помощью URI. В этом случае либо 200 (OK) или 204 (без содержимого) - соответствующий статус ответа, в зависимости от того, включает ли ответ объект, который описывает результат.
Первое важное значение имеет смысл GET и POST:
После этого можно заметить пару вещей:
В любом случае, я не думаю, что мы могли бы "жить" без GET: подумайте о том, сколько URL-адресов, которые вы используете с параметрами в строке запроса, каждый день - без GET, все это не сработает; -)
Помимо различия ограничений длины во многих браузерах, существует также семантическая разница. Предполагается, что GET "безопасен", поскольку они являются операциями только для чтения, которые не изменяют состояние сервера. POST обычно изменяет состояние и выдаст предупреждения при повторной отправке. Поисковые роботы поисковых систем могут создавать GET, но никогда не должны делать POST.
Используйте GET, если вы хотите читать данные без изменения состояния и использовать POST, если вы хотите обновить состояние на сервере.
Мое общее правило - использовать Get, когда вы делаете запросы на сервер, которые не будут изменять состояние. Сообщения зарезервированы для запросов на сервер, которые изменяют состояние.
Одно практическое отличие заключается в том, что браузеры и веб-серверы имеют ограничение на количество символов, которые могут существовать в URL-адресе. Он отличается от приложения к приложению, но, безусловно, его можно поразить, если у вас есть textarea в ваших формах.
Еще одна проблема с GET - они индексируются поисковыми системами и другими автоматическими системами. В Google появился продукт, который предварительно запрашивал ссылки на просматриваемой вами странице, поэтому их можно было бы быстрее загрузить, если бы вы нажали эти ссылки. Это вызвало значительный хаос на сайтах с такими ссылками, как delete.php?id=1 - люди потеряли все свои сайты.
Используйте GET, если вы хотите, чтобы URL-адрес отражал состояние страницы. Это полезно для просмотра динамически сгенерированных страниц, например, здесь. POST следует использовать в форме для отправки данных, например, когда я нажимаю кнопку "Опубликовать свой ответ". Он также создает более чистый URL-адрес, поскольку он не генерирует строку параметров после пути.
Поскольку GET - это чисто URL-адреса, они могут быть кэшированы веб-браузером и могут быть лучше использованы для таких вещей, как постоянно создаваемые изображения. (Установите время истечения срока действия)
Один пример из страницы gravatar: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid
GET может незначительно повысить производительность, некоторые веб-серверы записывают содержимое POST во временный файл перед вызовом обработчика.
Еще одна вещь, которую следует учитывать, - это ограничение по размеру. GET ограничены размером URL, 1024 байта по стандарту, хотя браузеры могут поддерживать больше.
Передача большего количества данных, чем это, должна использовать POST для улучшения совместимости браузера.
Еще меньше этого предела является проблемой, как писал другой плакат, что-либо в URL-адресе может оказаться в других частях пользовательского интерфейса браузера, например, истории.
Это пересекает концепцию REST и то, как веб-сайт был предназначен для использования. Существует отличный подкаст на радио Software Engineering, в котором подробно рассказывается об использовании Get и Post.
Get используется для извлечения данных с сервера, где действие обновления не требуется. Идея заключается в том, что вы должны иметь возможность использовать один и тот же запрос GET снова и снова и возвращать ту же самую информацию. URL-адрес содержит информацию о получении в строке запроса, поскольку она должна быть легко передана другим системам, а людям - адрес, где можно найти что-то.
Предполагается, что должно использоваться сообщение (по крайней мере, с помощью архитектуры REST, на которой основан веб-сайт) для передачи информации на сервер/передачи серверу действий. Примеры: обновите эти данные, создайте эту запись.
Нет ничего, что вы не можете сделать per se. Дело в том, что вы не должны изменять состояние сервера в HTTP GET. HTTP-прокси предполагают, что, поскольку HTTP GET не изменяет состояние, то независимо от того, вызывает ли пользователь HTTP GET один раз или 1000 раз, нет никакой разницы. Используя эту информацию, они полагают, что безопасно вернуть кэшированную версию первого HTTP GET. Если вы нарушите спецификацию HTTP, вы рискуете разбить HTTP-клиент и прокси-серверы в дикой природе. Не делайте этого:)
1.3 Быстрый контрольный список для выбора HTTP GET или POST
The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).
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.
Я не вижу проблемы с использованием get хотя, я использую его для простых вещей, где имеет смысл держать вещи в строке запроса.
Использование этого для обновления состояния - как GET для delete.php?id=5 для удаления страницы - очень рискованно. Люди узнали об этом, когда веб-ускоритель Google начал предварительную выборку URL-адресов на страницах - он ударил все ссылки "удалить" и уничтожил данные людей. То же самое может произойти с пауками поисковых систем.
POST может перемещать большие данные, в то время как GET не может.
Но, как правило, это не о сокращении GET, а скорее о согласии, если вы хотите, чтобы ваш веб-сайт/webapp хорошо себя вел.
От RFC 2616:
9.3 GET
Метод GET означает получение любой информации (в форме сущность) идентифицируется Request-URI. Если Request-URI ссылается к процессу создания данных, это данные, которые должны быть возвращены как субъект в ответе, а не исходный текст процесса, если только этот текст является результатом процесс.
9.5 POST
Метод POST используется для запроса, чтобы исходный сервер принять объект, заключенный в запросить в качестве нового подчиненного ресурс, идентифицированный Request-URI в строке запроса. POST разработан для обеспечения единообразного метода охвата следующие функции:
- Аннотация существующих ресурсов;
- Размещение сообщения на доске объявлений, в новостной группе, в списке рассылки или аналогичная группа статей;
- Предоставление блока данных, например, результата отправки формы, процесс обработки данных;
- Расширение базы данных с помощью операции добавления.
Фактическая функция, выполняемая Метод POST определяется сервера и обычно зависит от Request-URI. Опубликованный объект подчиненный этому URI в том же способ, которым файл подчинен каталог, содержащий его, новости статья подчинена группе новостей на который он отправлен, или запись подчиненной базе данных.
Действие, выполняемое POST метод может не привести к ресурсу которые могут быть идентифицированы с помощью URI. В этот случай, либо 200 (ОК), либо 204 (Нет Контент) - соответствующий ответ статус, в зависимости от того, ответ включает в себя объект, который описывает результат.
Я использую POST, когда я не хочу, чтобы люди видели QueryString или когда QueryString становится большим. Кроме того, для загрузки файлов требуется POST.
Я не вижу проблемы с использованием GET, хотя я использую его для простых вещей, где имеет смысл хранить вещи в QueryString.
Использование GET позволит также связывать конкретную страницу, где POST не работает.
GET и POST в основном позволяют отправлять информацию на веб-сервер из браузера (или другого HTTP-клиента).
Представьте, что у вас есть форма на странице HTML, и нажатие кнопки "отправить" отправляет данные в форме обратно на сервер, как пары "имя = значение".
Выбор GET в качестве "метода" добавит все данные в URL-адрес и отобразится в строке URL вашего браузера. Объем информации, которую вы можете отправить обратно с использованием GET, ограничен, поскольку URL-адреса могут содержать только 1024 символа.
Проблемы интеграции облаков Скачать сейчас POST с другой стороны (обычно) отправит информацию через сокет обратно на веб-сервер и не появится в строке URL. Вы можете отправить гораздо больше информации на сервер таким образом - и это также не ограничивается текстовыми данными. Можно отправлять файлы и даже двоичные данные, такие как сериализованные объекты Java!
Первоначальное намерение состояло в том, что GET использовался для получения данных назад, и POST должен был быть чем угодно. Эмпирическое правило, которое я использую, состоит в том, что если я отправляю что-либо обратно на сервер, я использую POST. Если я просто вызываю URL-адрес для возврата данных, я использую GET.
Прочитайте статью статью об HTTP в Википедии. Он объяснит, что такое протокол и что он делает:
GET
Запросит представление указанного ресурса. Обратите внимание, что GET не следует использовать для операций, которые вызывают побочные эффекты, например, для использования в веб-приложениях. Одна из причин этого заключается в том, что GET может использоваться произвольно роботами или искателями, которые не должны учитывать побочные эффекты, которые должен вызвать запрос.
и
POSTОтправляет данные, подлежащие обработке (например, из HTML-формы) в идентифицированный ресурс. Данные включены в тело запроса. Это может привести к созданию нового ресурса или обновлений существующих ресурсов или того и другого.
В W3C есть документ под названием URI, адресность и использование HTTP GET и POST, в котором объясняется, когда использовать что. Цитирование
1.3 Быстрый контрольный список для выбора HTTP GET или POST
- Используйте GET, если:
- Взаимодействие больше похоже на вопрос (т.е. это безопасную операцию, такую как запрос, операцию чтения или поиск).
и
- Используйте POST, если:
- Взаимодействие больше похоже на порядок, или
- Взаимодействие изменяет состояние ресурса таким образом, чтобы пользователь воспринимал (например, подписку на услугу) или o Пользователь будет привлечен к ответственности за результаты взаимодействия.
Однако перед окончательным решением использовать HTTP GET или POST, пожалуйста, также рассмотрите соображения для конфиденциальных данных и практических соображений.
Практический пример - всякий раз, когда вы отправляете HTML-форму. Вы указываете любой пост или получите для действия формы. PHP будет заполнять $_GET и $_POST соответственно.
В PHP ограничение данных POST обычно устанавливается вашим php.ini. GET ограничено настройками сервера/браузера, которые я считаю - обычно около 255 байтов.
Простая версия POST GET PUT DELETE используйте GET - когда вы хотите получить какой-либо ресурс, например Список данных на основе любого Идентификатора или имени используйте POST - когда вы хотите отправить какие-либо данные на сервер. имейте в виду, что POST - это тяжелая операция, потому что для обновления мы должны использовать PUT вместо POST внутри POST создаст новый ресурс используйте PUT - когда вы
От w3schools.com:
Что такое HTTP?
Протокол передачи гипертекста (HTTP) предназначен для включения связь между клиентами и серверами.
HTTP работает как протокол запроса-ответа между клиентом и сервером.
Веб-браузер может быть клиентом и приложение на компьютере, которое хостом веб-сайт может быть сервером.
Пример: клиент (браузер) отправляет HTTP-запрос серверу; то сервер возвращает ответ клиенту. Ответ содержит информацию о состоянии запроса и может также содержать запрошенный контент.
Два метода HTTP-запроса: GET и POST
Два часто используемых метода для запроса-ответа между клиентом и сервер: GET и POST.
GET - запрашивает данные из заданного ресурса POST - отправляет данные в обрабатываться на указанный ресурс
Здесь мы различаем основные отличия:
Gorgapor, mod_rewrite все еще часто использует GET. Он просто позволяет перевести более дружественный URL-адрес в URL-адрес с строкой запроса GET.
Другое отличие состоит в том, что POST обычно требует двух HTTP-операций, тогда как GET требует только одного.
Изменить: я должен уточнить - для общих шаблонов программирования. Как правило, ответ на POST с прямолинейной HTML-страницей является сомнительным дизайном по разным причинам, одним из которых является раздражающее "вы должны повторно отправить эту форму, хотите ли вы это сделать?" при нажатии кнопки "Назад".
Хорошо, одна важная вещь - все, что вы отправляете через GET, будет отображаться через URL-адрес. Во-вторых, как говорит Ceejayoz, существует ограничение на символы для URL-адреса.
Как утверждают другие, существует ограничение на размер url с get, и файлы могут быть отправлены только с сообщением.
Я хотел бы добавить, что один может добавлять вещи в базу данных с помощью get и выполнять действия с сообщением. Когда script получает сообщение или get, он может делать все, что хочет сделать автор. Я считаю, что недостаток понимания исходит из формулировки, которую выбрала книга, или как вы ее читаете.
A script author должен использовать сообщения для изменения базы данных и использовать get только для извлечения информации.
Языки сценариев предоставляют множество способов доступа к запросу. Например, PHP позволяет использовать $_REQUEST для получения сообщения или получения. Следует избегать этого в пользу более конкретных $_GET или $_POST.
В веб-программировании есть гораздо больше возможностей для интерпретации. Там какой должен и что может сделать, но лучше всего, это часто приходится обсуждать. К счастью, в этом случае нет никакой двусмысленности. Вы должны использовать сообщения для изменения данных, а вы должны использовать для получения информации.
Данные HTTP-сообщения не имеют определенного ограничения на количество данных, где, поскольку разные браузеры имеют разные пределы для GET. В RFC 2068 говорится:
Серверы должны быть осторожны в зависимости от длины URI выше 255 байтов, потому что некоторые старые клиенты или реализация прокси-сервера может не выполняться должным образом поддерживать эти длины
В частности, вы должны использовать правильные HTTP-конструкции для того, для чего они используются. HTTP GET не должен иметь побочных эффектов и может быть безопасно обновлен и сохранен HTTP-прокси и т.д.
HTTP POST используются, когда вы хотите отправить данные против ресурса url.
Типичным примером использования HTTP GET является поиск, т.е. поиск? Query = my + query Типичным примером использования HTTP POST является отправка обратной связи в онлайн-форму.