Получить сопоставление и сопоставление сообщений весны-mvc [дубликат]
Перед вызовом метода экземпляра или переменной экземпляра ему нужен объект (экземпляр). Когда экземпляр переменной вызывается из статического метода, компилятор не знает, к какому объекту принадлежит эта переменная. Поскольку статические методы не имеют объекта (только одна копия всегда). Когда вы вызываете переменную экземпляра или методы экземпляра из метода экземпляра, она ссылается на объект this. Это означает, что переменная принадлежит к любому объекту, созданному, и каждый объект имеет свою собственную копию методов и переменных экземпляра.
Статические переменные отмечены как static, а переменные экземпляра не имеют определенного ключевого слова.
18 ответов
Так как вы пишете серверное программное обеспечение (предположительно), то это волнует, если вы расскажете ему об этом. Если вы обрабатываете данные POST и GET одинаково, то нет, это не так.
Однако браузер определенно заботится. Обновление или щелчок назад к странице, которую вы получили в ответ на POST, выдает небольшую подсказку «Вы уверены, что хотите отправить данные снова», например.
-
1Что еще более важно, вы можете использовать шаблон Post / Redirect / Get, чтобы люди не могли случайно повторить действия. – Wedge 8 July 2009 в 22:03
-
2Однако это можно обойти, если ваш код, обрабатывающий запрос POST, никогда ничего не отображает, а перенаправляет на страницу, которая делает это. См. ru.wikipedia.org/wiki/Post/Redirect/Get – Ken Keenan 8 July 2009 в 22:04
-
3Конечно. И это в значительной степени мое мнение. С точки зрения браузера важно, отправляете ли вы данные через POST или GET, и поэтому они должны обрабатываться сервером по-разному. Я бы не назвал это «обходным путем». хотя, поскольку это означает, что поведение браузера является ошибкой. Он работает таким образом по совершенно веской причине, и "обходной путь" это совершенно логичный способ справиться с этим. – jalf 8 July 2009 в 22:11
Согласно HTTP RFC, GET не должен иметь побочных эффектов, в то время как POST может иметь побочные эффекты.
Самый простой пример: GET не подходит ни для чего, -транзакция или публикация статьи в блоге, в то время как POST подходит для действий, которые имеют последствия.
В RFC вы можете удерживать пользователя, ответственного за действия, выполняемые POST (например, покупка ), но не для действий GET. «Боты всегда используют GET по этой причине.
Из RFC 2616, 9.1.1 :
9.1.1 Безопасные методы
Разработчики должны знать, что программное обеспечение представляет пользователя в их взаимодействиях через Интернет и должно быть осторожным, чтобы позволить пользователю быть в курсе любых действий, которые они могут предпринять, что может иметь неожиданное значение для себя или для других.
В частности, было установлено, что методы GET и HEAD НЕ ДОЛЖНЫ иметь значение принятия иного действия, кроме поиска. Эти методы следует считать «безопасными». Это позволяет агентам пользователя представлять другие методы, такие как POST, PUT и DELETE, особым образом, чтобы пользователь был осведомлен о том, что запрашивается возможно небезопасное действие.
Естественно, невозможно гарантировать, что сервер не генерирует побочные эффекты в результате выполнения запроса GET; на самом деле, некоторые динамические ресурсы считают эту особенность. Важным отличием здесь является то, что пользователь не запрашивал побочные эффекты, поэтому не может быть привлечен к ответственности за них.
По спецификациям 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 и всегда была очень хорошо решена. Игнорируйте его на свой страх и риск.
Технически сервер не может заботиться о том, какой запрос он получает. Он будет слепо выполнять любой запрос, проходящий через провод.
В чем проблема. Если у вас есть действие, которое уничтожает или изменяет данные в действии GET, Google будет разорвать ваш сайт, когда он сканирует индексирование.
Имейте в виду, что браузеры могут кэшировать запросы GET, но обычно не кэшируют запросы POST.
-
1
-
2Даже с разрешения злоумышленники могут отправить электронное письмо с & lt; img src = & quot; example.com/items.aspx?id=5&mode=delete & quot; & gt; & gt; кому-то, кто уже вошел в систему. – Paco 8 July 2009 в 22:01
-
3@Paco: Если ваш браузер загружает этот img, он будет использовать GET. Веб-сервер НЕ должен делать такие действия, как «удаление», основанный на GET-запросе именно по этой причине. Ответственность веб-сервера заключается в том, чтобы обеспечить выполнение серьезных действий только через запросы POST. – abelenky 8 July 2009 в 22:06
-
4
Технически, нет. Все GET - это публикация материала в первой строке HTTP-запроса, а POST-сообщения в теле.
Однако, как «веб-инфраструктура» рассматривает различия, мир становится разным. Мы могли бы написать целую книгу об этом. Тем не менее, я дам вам несколько «лучших практик»:
Используйте «POST», когда ваш HTTP-запрос изменит что-то «конкретное» внутри веб-сервера. Т.е. вы редактируете страницу, создаете новую запись и так далее. POSTS с меньшей вероятностью будут кэшироваться или рассматриваться как нечто «повторяемое без побочных эффектов»
Используйте «GET», если вы хотите «посмотреть на объект». Теперь такой взгляд может изменить что-то «за кулисами» с точки зрения кеширования или записи, но он не должен ничего менять «существенным». То есть, я мог бы повторять мой GET снова и снова, и ничего плохого не произошло бы, кроме завышенных значений хита. GET должны быть легко заклассифицированы, поэтому пользователь может вернуться к этому же объекту позже.
Параметры для GET (материал после «?» Традиционно) следует рассматривать как «атрибуты представления» или «что посмотреть» и так далее. Опять же, это не должно ничего менять: используйте POST для этого.
И последнее слово, когда вы POST что-то (например, вы создаете новый комментарий), имеете обработку для post выдает 302, чтобы «перенаправить» пользователя на новый URL-адрес, который рассматривает этот объект. Т.е. POST обрабатывает информацию, затем перенаправляет браузер в инструкцию GET для просмотра нового состояния. Отображение информации в результате POST также может вызвать проблемы. Выполнение перенаправления часто используется и улучшает работу.
-
1«Технически, нет». Это немного странно. Я имею в виду, что все, что мы программисты делаем, это единицы и нули в конце дня, так что «технически», нет никакой разницы между большей частью чего-либо! Авторитарной ссылкой здесь является спецификация HTTP (rfc 2616), которая делает техническое различие в разделе 9. – ars 8 July 2009 в 23:04
-
2ars: К сожалению, то, что спецификация HTTP не упоминает, - это то, какие приложения (например, веб-сервер, cgi-скрипты, веб-приложения) используют эту информацию. Это невозможно узнать из спецификации HTTP. Таким образом, согласно спецификации, единственная разница заключается в том, как информация отправляется на HTTP-сервер. В зависимости от получателя (программа, которая получает данные) может быть разница ZERO между GET и POST, или мир различий. Итак, мой ответ: «если вы сделаете это так, вы столкнетесь с меньшими проблемами, чем если бы вы сделали это любым другим способом». – Ch'marr 4 September 2009 в 00:28
Вы знаете несколько тонких различий в безопасности. См. Мой вопрос
GET по сравнению с POST с точки зрения безопасности?
По сути важно помнить, что GET пойдет в историю браузера и будет передаваться через прокси в виде простого текста, поэтому вам не нужна какая-либо конфиденциальная информация, например пароль в GET.
Очевидно, возможно, но стоит упомянуть.
GET имеет ограничения на ограничение данных на основе отправляющего браузера:
Спецификация для длины URL-адреса не определяет минимальную или максимальную длину URL-адреса, но реализация зависит от браузера. В Windows: Opera поддерживает ~ 4050 символов, IE 4.0+ поддерживает ровно 2083 символа, Netscape 3 -> 4.78 поддерживает до 8192 символов, прежде чем вызывать ошибки при выключении, а Netscape 6 поддерживает ~ 2000 перед возникновением ошибок при запуске
-
1Также может быть ограничение на запросы GET на стороне сервера. Например, Apache имеет ограничение по умолчанию, установленное на 8190 байт – Mattias Wadman 2 September 2011 в 11:03
Нет, они не должны за исключением @ jbruce2112 Ответ и загрузка файлов требуют POST.
Да, это имеет значение. GET и POST на самом деле очень разные.
Вы правы в этом, как правило, GET - это «получение» данных с сервера и отображение страницы, а POST - для «отправки» данных на сервер , Внутри ваши сценарии получают одни и те же данные, будь то GET или POST, поэтому нет, сервер действительно не заботится.
Основное отличие - параметры GET указаны в URL-адресах, а POST - нет. Вот почему POST используется для регистрации и регистрационных форм - вы не хотите, чтобы ваш пароль был указан в URL-адресе. Точно так же, если вы просматриваете разные страницы или показываете конкретный вид некоторых данных, вам обычно нужен уникальный URL.
-
1Не передавая свой пароль в URL-адресе, нет никакой безопасности, и нет способа пройти через жизнь, сын. (Гринь). Если вы используете обычный текст (HTTP против HTTPS), ваш пароль будет виден, будет ли его POST или GET. – abelenky 8 July 2009 в 21:51
-
2Я никогда не говорил, что POST был более безопасным вообще, я сказал, что вам не нужен ваш пароль в URL-адресе. Что произойдет, если пользователь разместит этот URL на форуме или что-то еще? – DisgruntledGoat 9 July 2009 в 16:38
Если пользователь сможет закладок на полученной странице? Еще одна вещь, о которой стоит подумать, - некоторые браузеры / серверы неправильно ограничивают длину URI GET.
Изменить: исправлено ограничение длины символа - спасибо ars!
-
1jbruce211: Это ограничение, основанное на реализациях (например, браузерах или http-серверах). Это не является пределом, присущим GET для спецификации HTTP. Из спецификации: «HTTP-протокол не устанавливает априорного предела длины URI. Серверы ДОЛЖНЫ иметь возможность обрабатывать URI любого ресурса, который они обслуживают, и ДОЛЖНЫ иметь возможность обрабатывать URI неограниченной длины, если они предоставляют формы на основе GET, которые могут генерировать такие URI. & Quot; w3.org/Protocols/rfc2616/rfc2616-sec3.html – ars 8 July 2009 в 23:00
Если вы используете запрос GET для изменения состояния на заднем плане, вы рискуете иметь плохие вещи, если какой-либо веб-браузер каким-то образом пересекает ваш сайт. Назад, когда wikis впервые стал популярным, были ужасные истории о удалении целых сайтов, потому что функция «удалить страницу» была реализована как запрос GET с катастрофическими результатами, когда робот Googlebot стучал ...
Это зависит от программного обеспечения на сервере. Некоторые библиотеки, такие как CGI.pm в perl, обрабатывают оба по умолчанию. Но бывают ситуации, когда вы более или менее должны использовать POST вместо GET, по крайней мере для того, чтобы нажимать данные на сервер. Большие объемы данных (где соответствующий URL-адрес GET станет слишком длинным), двоичные данные (во избежание проблем с кодированием / декодированием), многочастные файлы, не прошедшие анализ заголовков (для непрерывного обновления до AJAX-стиля ...) и аналогичных .
Сервер обычно не заботится. Но, как вы упомянули, это в основном для соблюдения передовых практик. Клиентская сторона также имеет значение - как уже упоминалось, вы не можете обычно класть закладку POST'd, а некоторые браузеры имеют ограничения на длину URL-адреса для действительно длинных запросов GET.
Я думаю, что более подходящий ответ, вы можете в значительной степени сделать то же самое с обоими. Однако речь идет не только о предпочтении, но и о правильном использовании. Я бы рекомендовал вам использовать GET и POST, как они предназначены для .
GET имеет ограничения на стороне браузера. Например, некоторые браузеры ограничивают длину запросов GET.
«Используйте GET, если: взаимодействие больше похоже на вопрос (т. е. это безопасная операция, такая как запрос, операция чтения или поиск).»
«Использовать POST, если: взаимодействие больше похоже на заказ, или взаимодействие изменяет состояние ресурса таким образом, чтобы пользователь воспринимал (например, подписку на услугу), или пользователь считался ответственным за результаты взаимодействия ».
Поскольку GET предназначен для указания ресурса, который вы хотите получить, в зависимости от точного программного обеспечения на стороне сервера, веб-сервер (или балансировщик нагрузки перед ним) может иметь ограничение размера для запросов GET для предотвращения атак типа «отказ в обслуживании» ...