Смешивание GET с POST - это плохая практика?

Плохо ли смешивать GET и POST? (обратите внимание, что это в PHP)

e.g.

<form action="delete.php?l=en&r=homepage" method="post">
 <!-- post fields here -->
</form>

person mauris    schedule 20.10.2009    source источник
comment
Может быть, будет больше смысла, если вы спросите, является ли это ПЛОХОЙ практикой   -  person Joe Phillips    schedule 20.10.2009
comment
@d03boy - да, так и думал. изменится   -  person mauris    schedule 20.10.2009
comment
В соответствии с этим dev.ckeditor.com/ticket/727 смешивание GET и POST может даже не сработать, хотя Я еще не видел его. Так что интересно, это когда-нибудь потерпит неудачу?   -  person Trilarion    schedule 24.03.2015


Ответы (3)


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

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

РЕДАКТИРОВАТЬ, годы спустя

Меня попросили указать источник, поэтому вот соответствующая часть самой спецификации HTTP.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

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

Итак, GET не должен ничего менять, POST предназначен для изменения сервера (небезопасная операция). Я должен иметь возможность вызывать GET любое количество раз. Это больше, чем идемпотент: он должен быть (насколько это возможно) свободным от побочных эффектов! При использовании GET запрос может даже не достичь сервера, если задействовано кэширование.

Так что да: у вас есть форма, хотите знать, используете ли вы GET или POST? Затем измените сервер => POST, не меняйте сервер => GET. А поскольку доступ к URL-адресу можно получить с помощью любых глаголов (получить или опубликовать), не помещайте данные, которые изменяют сервер, в URL-адрес, потому что кто-то может скопировать этот URL-адрес, выполнить GET и изменить ваш сервер без вашего ведома. . Представьте, что произойдет, если кто-то скопирует этот URL-адрес на Facebook, и 10 000 человек начнут удалять случайные вещи? Фигово. Последние фреймворки (node, ruby) лучше защищены от этого, но не базовый PHP, так что это хорошее практическое правило для этого языка.

person Laurent Bourgault-Roy    schedule 20.10.2009
comment
Это слишком упрощено. Во-первых, GET следует использовать только в том случае, если действие является идемпотентным. - person Jeroen; 05.04.2013
comment
Я хотел бы увидеть какие-либо резервные ресурсы для этого заявления. - person atamanroman; 25.02.2014
comment
Я добавил источник. Я считаю, что ответ должен быть менее кратким, но лучше объясненным. - person Laurent Bourgault-Roy; 25.02.2014

Это все еще POST, вы просто включаете строку запроса в URL-адрес. Я не вижу в этом проблемы. Это, вероятно, чище, чем включение этих переменных в данные публикации с использованием скрытых полей ввода. Кроме того, на сервере вам, вероятно, не нужно значение l (язык?) с вашими данными сообщения. Если он всегда находится в строке запроса, вы можете использовать тот же код в другом месте, чтобы определить язык, вместо того, чтобы использовать специальный случай для запросов POST.

person Joel    schedule 20.10.2009
comment
Это лучший ответ, чем ответ Джона Кугельмана. Я считаю, что включение параметров, идентифицирующих программу или окружение, допустимо (например, ?action=deleteUser&language=en), возможно, это даже хорошая практика, когда включение идентификатора того, что вы хотите действовать в соответствии с плохой практикой (например, ?userId=123). Это относится к скрытому полю. - person marc82ch; 03.02.2014

Нет, это нормально. Я делаю именно это на веб-сайте моей компании, например, на странице администратора пользователя. Обычный URL:

/admin/user?name=jkugelman

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

<!-- Post back to self -->
<form action="/admin/user?name=jkugelman">
    <input type="submit" name="delete" value="Delete"
           onchange="return confirm('Are you sure?')" />
</form>
person John Kugelman    schedule 20.10.2009
comment
Что ж, в идеале удаление должно быть выполнено с помощью действия DELETE, если только HTML позволит вам. - person Kieron; 20.10.2009
comment
я думаю, что это довольно плохая реализация, если вы спросите меня. я помещу имя пользователя в скрытое поле. - person mauris; 20.10.2009