Если вы занимались какой-либо веб-разработкой, вы, должно быть, встречали эти два термина GET & POST. Эти термины вводятся в отношении тега формы. Объяснение было таким:
«В теге формы есть атрибут, называемый методом. Здесь вы можете указать, каким образом вы хотите отправлять данные на серверную часть. У этого атрибута есть два значения: GET и POST».
GET: если вы используете этот метод, то данные, которые вы записали в форме, будут добавлены к URL-адресу и будут отправлены. Поскольку вводимые пользователем данные чётко видны в URL-адресе, этот метод небезопасен, и существует ограничение на то, что вы можете отправить, и сколько вы можете отправить.
POST: если вы используете POST, данные будут отправлены в теле HTTP-запроса. Его не будет видно в URL-адресе. Нет ограничений на объём отправляемых данных. POST также поддерживает отправку любых данных.
Чем отличается POST от GET
Я повсюду наблюдал, как GET и POST представлены студентам именно так. Хотя этого подробного объяснения достаточно для использования GET и POST в контексте форм, они не дают чёткого понимания этих двух методов.
Ниже приводится объяснение с примером. В примерах мы будем использовать код PHP. (Мы использовали $ _REQUEST для сбора данных, чтобы один и тот же файл можно было использовать для обоих).
Синтаксис:
<?
php echo «Привет». $ _ REQUEST [‘name’]. «!!»;
?>
GET: вот код формы GET.
filter_none
редактировать
play_arrow
яркость_4
|
Выход
Как и ожидалось, значения параметров появились в URL-адресе. Но если мы воспользуемся инструментом проверки хрома для более подробного анализа, мы сможем увидеть значения, которые представлены в разделе «Параметры строки запроса».
POST: вот код формы POST. Если вы заметили, она идентична нашей форме GET, за исключением значения атрибута method.
filter_none
редактировать
play_arrow
яркость_4
|
Выход
Данные отправлены. Но теперь, если мы проверим его с помощью инструментов Chrome, параметры появятся в разделе «Данные формы». GET и POST относятся к семейству HTTP-методов (отсюда и произошло название метода атрибута). Некоторые из методов HTTP: GET, PUT, POST, DELETE, HEAD, PATCH, OPTIONS, TRACE и т.д.
Все они служат нескольким целям протокола HTTP. В этой статье мы в основном сосредоточимся на первых четырёх.
CRUD-операции
Если вы работаете с базами данных, вы, должно быть, встречали эти термины. С точки зрения непрофессионала, я могу объяснить CRUD как базовую функциональность, которая должна предоставляться конечным пользователям через API, чтобы иметь возможность правильно использовать любую систему управления базами данных (в контексте веб-разработки это будет СУБД, которую вы используете вместе со своим сервером. код, скажем MySql, Hibernate и т. д.). CRUD означает CREATE, READ, UPDATE и DELETE. Четыре метода HTTP, как я упоминал ранее, соответствуют одной из этих операций.
- CREATE: команда SQL будет использоваться для создания записи в базе данных. Метод HTTP, соответствующий этой операции, — POST, так как в теле запроса вы будете добавлять значения «POSTING» в базу данных).
Вставить в TABLENAME ЗНАЧЕНИЯ (value1_for_column1, value2_for_column2…);
- ЧТЕНИЕ: используется для чтения записи, которая уже присутствует в БД. Можно специально запросить записи, которые он / она хочет прочитать, используя предложение WHERE. Команда SQL будет такой:
ВЫБРАТЬ * из ГДЕ столбецX = значениеX И столбецY> значениеY…;
HTTP-метод, соответствующий этой операции, — GET. Попробуйте сравнить это с URL-адресом, сгенерированным после запроса GET, то есть с частью после ’?’ отметьте в URL-адресе выражение после предложения WHERE. Они оба очень похожи, не так ли?
- ОБНОВЛЕНИЕ: используется для обновления записи в БД. Соответствующий метод HTTP — PUT. В SQL мы можем добиться этого с помощью оператора UPDATE.
- DELETE: это как бы говорит само за себя. Хочется удалить запись. И метод HTTP, и команда SQL будут УДАЛИТЬ.
Теперь, если вы подумаете о результатах, которые у нас были ранее, это имеет гораздо больше смысла. Для GET тело запроса было пустым, а значения находились в параметре строки запроса. Поскольку поля формы обрабатывались как параметр запроса, запрашиваемого по URL-адресу «localhost / target.php».
В методе POST данные, введённые в форму, шли вместе с телом запроса. Так оно и появилось в разделе Form Data. Он обрабатывается как некоторые данные, которые пользователь хочет отправить, а не как параметры запроса.
GET и POST: теперь давайте немного вернёмся и подумаем с точки зрения разработчика протокола HTTP. Мы знаем, что GET разработан для использования в случаях, когда пользователь запрашивает список записей. Поля, по которым пользователь выполняет поиск, обычно очень маленькие и текстовые. Таким образом, для запроса GET нет необходимости разрешать что-либо, кроме текстов и всего, что превышает 30 КБ. Скорее, если мы сохраним небольшой размер, задержка обработки будет уменьшена.
Теперь, имея в виду эти вещи, попробуйте подумать о некоторых приложениях, которые вы используете ежедневно, где, по вашему мнению, используется GET. Да! Поисковые системы. Теперь откройте поисковик и попробуйте что-нибудь поискать. Обратите внимание на появившийся URL.
Поиск Bing:
Поиск Гугл:
Давайте снова подумаем о разработчиках HTTP. Посредством POST пользователь будет создавать новые записи, для которых потребуется передать большой объём данных. Такой объём данных не может быть передан через URL-адрес, поэтому лучше отправлять их как HTTP-пакеты. Более того, запись может содержать некоторые личные данные, поэтому метод POST должен быть безопасным. Следовательно, POST используется с формами, которые имеют дело с пользовательскими данными (например, с формами Google, когда вы создаёте новую учётную запись на GfG).
С тех пор как я говорил о создании учётной записи, вы можете спросить: «А как насчёт входа в систему? Там никаких новых рекордов не создаётся! Тогда почему GET там не используется?» Хотя можно просто отбросить этот вопрос, сказав, что GET небезопасен, мы не используем его для входа в систему. Но давайте подумаем об этом в контексте, который мы обсуждали до сих пор. При входе в систему вы на самом деле не запрашиваете / не ищете свою запись. Давайте рассмотрим логин с точки зрения поиска. Затем вы передаёте имя пользователя и пароль и спрашиваете систему, есть ли какая-либо учётная запись с этими учётными данными. Это будет очень неправильно. Когда мы авторизуемся, мы запрашиваем у системы разрешение на взаимодействие с нашими данными. По аналогии с банком login будет просить менеджера предоставить нам ключ, который откроет наш шкафчик, во время поиска будет спрашивать, есть ли у человека X шкафчик в этом банке или нет, что опять же очень неправильно и сводит на нет всю цель конфиденциальности. Итак, если вы поставите правильную подпись, менеджер предоставит вам ключ, который откроет шкафчик. В веб-разработке сервер предоставит вам sessionId.
Подведём итоги. При входе в систему, если учётные данные верны, серверная часть создаст для вас сеанс и предоставит идентификатор сеанса. Теперь, используя sessionId, вы можете искать свои данные. Итак, POST подходит для этой ситуации. И, войдя в систему, вы можете использовать запросы GET для извлечения данных.
Заключение
Подводя итог, GET используется для чтения / доступа к некоторым ресурсам, а POST используется для его создания. Я бы посоветовал вам не ограничивать себя мыслительным ресурсом по отношению к СУБД, а подумать об этом в более широком смысле. Ресурс может быть любым, начиная от строки в базе данных и заканчивая файлами, такими как изображения или текст, а иногда даже полными HTML-страницами. Если вы хотите читать / искать ресурс, используйте GET, а если вы хотите создать / добавить / загрузить ресурс, используйте POST.
