Запутался по поводу глаголов Http

Question

Я запутался, когда и почему вы должны использовать определенные глаголы в REST?

Я знаю основные вещи, такие как:

Get -> for retrieval
Post -> adding new entity
PUT -> updating
Delete -> for deleting

Эти атрибуты должны использоваться согласно операции, которую я написал выше, но я не понимаю, почему? Что произойдет, если внутри метода Get в REST я добавлю новую сущность или внутри POST я обновлю сущность? или может быть внутри УДАЛИТЬ Я добавить сущность. Я знаю, что это может быть нубский вопрос, но мне нужно это понять. Это звучит очень смущающе для меня.

Answer 1

@ archil отлично объясняет ловушек неправильного использования глаголов, но я хотел бы отметить, что правила не так жестки, как вы описали (по крайней мере, в отношении протокола обеспокоен).

• ПОЛУЧИТЕ ДОЛЖЕН быть безопасным. Это означает, что запрос GET не должен каким-либо существенным образом изменять состояние сервера. (Сервер может выполнять дополнительную работу, например, регистрировать запрос, но не обновляет данные.)
• PUT и DELETE ДОЛЖНЫ быть идемпотентными. Это означает, что несколько вызовов на один и тот же URI будут иметь тот же эффект, что и один вызов. Так, например, если вы хотите изменить имя человека с «Jon» на «Jack», и вы делаете это с помощью запроса PUT, это нормально, потому что вы можете сделать это один раз или 100 раз, а имя человека все равно будет обновлено. «Джеку».
• POST не дает никаких гарантий относительно безопасности или идемпотентности. Это означает, что технически вы можете делать все, что захотите, с помощью запроса POST. Тем не менее, вы потеряете любое преимущество, которое клиенты могут принять из этих предположений. Например, вы можете использовать POST для выполнения поиска, что семантически больше GET-запроса. Проблем не будет, но браузеры (или прокси-серверы или другие агенты) никогда не будут кэшировать результаты этого поиска, потому что он не может предположить, что в результате запроса ничего не изменилось. Кроме того, веб-сканеры никогда не будут выполнять запрос POST, поскольку не могут предполагать, что операция безопасна.

Вся HTML-версия всемирной паутины довольно хорошо обходится без PUT или DELETE, и это прекрасно для удаления или обновления с помощью POST, но если вы можете поддерживать PUT и DELETE для обновлений и удалений (и других идемпотентных операций) это немного лучше, потому что агенты могут предположить, что операция идемпотентна.

См. официальную документацию W3C , чтобы узнать о мельчайших подробностях о безопасности и идемпотентности.

Answer 2

Протокол является протоколом. Он предназначен для определения каждого правила, связанного с ним. HTTP тоже протокол. Все вышеперечисленные правила (включая правила глагола http) определены протоколом http, а использование - протоколом http. Если вы не будете следовать этим правилам, только вы поймете, что происходит внутри вашего сервиса. Он не будет следовать правилам протокола и будет сбивать с толку других пользователей. Был один раз пример с известным фото-сайтом (неважно, какой), который действительно удалял картинки с помощью запроса GET. Как только пользователь этого сайта установил программу поиска Google Desktop, она архивирует страницы локально. Так как эта программа знала, что операции GET используются только для получения данных и не должна влиять на что-либо, она выполняла запросы GET для каждого доступного URL-адреса (включая эти URL-адреса GET-delete). Поскольку пользователь вошел в систему и cookie находился в браузере, проблем с авторизацией не было. И результат - все пользовательские фотографии были удалены на сервере из-за неправильного использования протокола http и глагола GET. Вот почему вы всегда должны следовать правилам протокола, который вы используете. Хотя это технически возможно, это не правильно переопределять определенные правила.

Answer 3

Использование GET для удаления ресурса было бы похоже на именование и документирование функции для добавления чего-либо в массив, который удаляет что-то из массива под капотом.REST имеет только несколько четко определенных методов (глаголы HTTP).Пользователи вашего сервиса будут ожидать, что ваш сервис придерживается этих определений, иначе это не RESTful веб-сервис.

Answer 4

Если вы сделаете это, вы не сможете заявить, что ваш интерфейс RESTful. Принцип REST требует, чтобы указанные глаголы выполняли действия, которые вы упомянули. Если они этого не делают, то его нельзя назвать интерфейсом RESTful.