В этой статье мы подробно рассмотрим наиболее популярные методы HTTP-запросов для REST API, выясним в чём разница между методами Post, Get, Put, Delete и Patch и как их всех использовать!

Что такое HTTP-запрос?

Если API - это способ общения приложений друг с другом, то HTTP-запросы - это предложения. И так же, как и предложения, мы можем разделить их на группы в зависимости от цели предложения: хотим ли мы что-то спросить или передать сообщение.

Итак, в REST API HTTP-запросы делятся на методы в зависимости от их назначения.

Вот самые используемые методы:

GET
POST
PUT
DELETE
PATCH

Давайте разберёмся, что это за методы, шаг за шагом!

Метод GET

Понимание HTTP GET-запросов

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

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

Коды ответов для GET-запросов

Когда делается GET-запрос, сервер отвечает различными кодами состояния в зависимости от результата:

Код состояния 200 (OK) означает, что запрос был успешным, и сервер возвращает запрошенную информацию, что является прямым примером успешного GET-запроса.
Код состояния 404 (NOT FOUND) указывает, что запрашиваемый ресурс не может быть найден на сервере, подчеркивая ключевой результат GET-запроса.
Код состояния 400 (BAD REQUEST) возвращается, если запрос был неправильно сформирован, указывая на важность правильного структурирования HTTP-запросов.

Эти ответы имеют решающее значение для понимания разработчиками того, как обрабатываются их запросы, и являются частью изучения HTTP методов, включая GET, POST и PUT.

Практические примеры GET-запросов

Давайте рассмотрим несколько практических примеров использования GET-запросов:

Получение списка учетных записей пользователей: HTTP GET http://www.exampledomain.com/accounts
Получение подмножества учетных записей пользователей с определенными параметрами: HTTP GET http://www.exampledomain.com/accounts?limit=20&offset=5
Доступ к деталям определенной учетной записи пользователя: HTTP GET http://www.exampledomain.com/accounts/123
Получение подробной информации об адресе пользователя: HTTP GET http://www.exampledomain.com/accounts/123/details

Метод POST

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

В контексте RESTful сервисов POST в основном используется для добавления нового объекта в коллекцию ресурсов, что является центральным процессом в понимании разницы между get и post, а также взаимодействием get post put.

Важно отметить, что ответы на методы POST не кэшируются, если это не указано в полях заголовков Cache-Control или Expires, что отличает POST от GET-запросов с точки зрения поведения кэширования.

В отличие от GET-запросов, POST не является ни безопасным, ни идемпотентным. Это означает, что последовательное выполнение идентичных post-запросов приведет к созданию нескольких уникальных ресурсов, подчеркивая практические последствия post и get, post и put, а также более широкий ландшафт методов запросов.

Коды ответов для POST API

Когда операция POST успешно создает новый ресурс на сервере, подходящим ответом является код состояния 201 (Created). Этот ответ должен детализировать результат запроса, ссылаться на новый ресурс и включать заголовок Location, предоставляя реальные примеры post-запросов и результатов ответов HTTP post.

Есть случаи, когда действие POST не приводит к уникально идентифицируемому ресурсу. В таких ситуациях сервер может вернуть статус 200 (ОК) или 204 (No Content), отражая нюансы различий в запросах post vs put, get vs post и общую структуру методов запросов.

Демонстрация POST-запросов на примерах

Для иллюстрации рассмотрим эти примеры URI, которые воплощают практику post to url и метод POST:

Создание нового профиля пользователя: HTTP POST http://www.exampledomain.com/accounts
Добавление определенных деталей в профиль пользователя: HTTP POST http://www.exampledomain.com/accounts/123/details

Метод PUT

Используйте PUT API в основном для обновления существующего ресурса (если ресурс не существует, API может решить создать новый ресурс или нет).

Если запрос проходит через кэш и Request-URI идентифицирует один или несколько текущих кэшированных объектов, эти записи ДОЛЖНЫ рассматриваться как устаревшие. Ответы на метод PUT не кэшируются.

Коды ответов для PUT API

HTTP PUT-запросы имеют решающее значение для настройки существующего онлайн-контента или добавления новых элементов, если они еще не существуют. Этот метод блистает, когда вы обновляете детали на веб-странице или отправляете новые записи, балансируя на грани между тем, что такое put-запрос и решениями put vs post. Это фундаментальный инструмент в наборе разработчика, особенно при обсуждении использования post и put или исследовании нюансов действий put и post.

Если PUT-запрос проходит через цифровое хранилище (кэш) и обнаруживает, что он адресован к уже сохраненному контенту, он помечает этот контент как устаревший. Интересно, что результаты этих PUT-действий не задерживаются в кэше, отличая их от того, как обрабатываются get и post запросы. Это различие имеет решающее значение в разнице между get и post, а также в понимании стратегического развертывания операций get post put в веб-разработке.

Ключевые моменты об ответах PUT

Если PUT создает что-то новое, веб-сервер сообщит вам об этом сообщением 201 (Created). Это проясняет некоторый туман вокруг HTTP post ответа и когда делать post to url.
Изменение чего-то уже существующего будет одобрено сообщением 200 (OK) или простым уведомлением 204 (No Content). Это лаконичный способ различить действия метода put и дебаты put и post.

Примеры PUT в действии

Давайте посмотрим, как PUT работает:

Для обновления информации о пользователе, вы бы использовали: HTTP PUT http://www.exampledomain.com/accounts/123
Изменение данных учетной записи? Попробуйте: HTTP PUT http://www.exampledomain.com/accounts/123/details

Метод DELETE

Как работает DELETE в веб-API

Функция DELETE в веб-API проста: она удаляет ресурсы, на которые вы указываете их веб-адресами (URI).

Вот что интересно в DELETE: он должен работать одинаково каждый раз. Если вы что-то удаляете, оно должно оставаться удаленным. Но некоторые люди утверждают, что, поскольку элемента больше нет, попытка удалить его снова на самом деле не делает то же самое, что может заставить вас задуматься о том, всегда ли DELETE работает одинаково. Это тема, которую некоторые люди любят обсуждать и видят по-разному.

Если ваш DELETE-запрос проходит через место, где сохраняется веб-информация (например, кэш) и находит данные по тому же адресу, эти данные должны быть помечены как устаревшие. И просто для вашего сведения, ответы, которые вы получаете от DELETE, не сохраняются в этом кэше.

Что происходит после DELETE

То, что происходит после нажатия DELETE, может немного отличаться:

Вы можете получить статус 200 (OK), если сервер сообщает вам, как прошло удаление.
Если сервер все еще думает об этом и ваш запрос на удаление ждет своей очереди, вы увидите статус 202 (Accepted).
Иногда сервер выполняет то, что вы просили, но не дает вам никаких подробностей. В этом случае вы увидите статус 204 (No Content).

Если вы попытаетесь удалить одно и то же дважды, второй раз на самом деле ничего нового не произойдет, потому что элемент уже был удален в первый раз. Поэтому вы, вероятно, получите 404 (NOT FOUND), потому что с точки зрения сервера там больше нечего удалять.

Примеры URI с обновленными ссылками

Чтобы удалить профиль пользователя: HTTP DELETE http://www.exampledomain.com/accounts/123
Чтобы удалить определенные данные учетной записи для пользователя: HTTP DELETE http://www.exampledomain.com/accounts/123/details

Метод PATCH

HTTP PATCH-запросы используются для частичного обновления ресурса.

Как и PATCH, PUT-запросы также могут изменять ресурс. Но вот более ясный способ думать об этом: используйте PATCH, когда вы хотите обновить только часть ресурса, и выбирайте PUT, когда вы планируете заменить целиком.

Однако имейте в виду, что использование PATCH в вашем приложении может столкнуться с некоторыми проблемами:

Не все веб-браузеры, серверы и фреймворки полностью поддерживают PATCH. Например, Internet Explorer 8, PHP, Tomcat, Django и многие другие либо вообще не поддерживают PATCH, либо обрабатывают его неправильно.

Как использовать методы GET/POST/PUT/DELETE без кода?

Ответ очевиден: используйте инструменты no-code/low-code для этого! Latenode - идеальный выбор, потому что он имеет узел HTTP-запроса, где вы можете использовать любой из этих методов для интеграции с ЛЮБЫМ приложением, которое имеет API.

Заключение

Теперь, когда вы вооружены знаниями о методах HTTP-запросов, таких как GET, POST, PUT, DELETE и PATCH, вы готовы перейти на следующий уровень понимания API.

Однако наше исследование на этом не заканчивается. Мы приглашаем вас погрузиться в нашу заключительную статью - REST API Headers & Body, чтобы еще больше усовершенствовать свое мастерство в API.

‍