Спецификация HTTP достаточно понятна, если вы прочитаете определение safe
:
Методы запроса считаются «безопасными», если их определенная семантика по существу доступна только для чтения; т.е. клиент не запрашивает и не ожидает какого-либо изменения состояния на исходном сервере в результате применения безопасного метода к целевому ресурсу. Кроме того, разумное использование безопасного метода не должно причинять вреда, потери имущества или необычного бремени на сервере происхождения.
Это определение безопасных методов не запрещает реализации включать в себя поведение, которое потенциально опасно, не только для чтения или вызывает побочные эффекты при вызове безопасного метода. Однако важно то, что клиент не запрашивал такого дополнительного поведения и не может нести за него ответственность. Например, большинство серверов добавляют информацию запроса для доступа к файлам журнала при завершении каждого ответа, независимо от метода и это считается безопасным, даже если хранилище журналов может заполниться и привести к сбою сервера. Аналогичным образом, безопасный запрос, инициируемый путем выбора рекламы в Интернете, часто будет иметь побочный эффект при взимании платы с рекламного аккаунта.
...
Таким образом, изменение состояния при загрузке, вызванной GET
, возможно, если клиент не знает об этом изменении состояния.
Тем не менее, в определенных ситуациях показ изменения состояния с помощью GET
может быть рискованным. Подумайте только о гусеничном шасси, которое вызывает пару URI, которые заказывают пиццу или тому подобное. Согласно спецификации это нормально, и сканер не должен нести ответственность за этот заказ. Это просто говорит вам, что это ваша вина.
С учетом вышесказанного вы всегда можете использовать POST
, если чувствуете себя некомфортно из-за определенных операций HTTP, поскольку POST
буквально позволяет обрабатывать запрос в соответствии с собственной семантикой ресурсов.
Что приводит меня к следующему пункту переосмысления вашего дизайна. Возвращать какой-то документ, который включает его собственное состояние, как-то странно, на мой взгляд. Обычно такая информация представляет собой метаданные о документе, но не сам ресурс. Здесь вы можете либо использовать HTTP-заголовки для передачи такой информации клиенту, либо спроектировать состояние этого ресурса как еще один ресурс, который вы можете подсказать клиенту о предоставлении ему ссылки для поиска, если он заинтересован.
В любом случае, выполнение изменения состояния при извлечении ресурса с помощью GET
не является элегантным, не запрещено. Хотелось бы еще немного подумать о том, хотите ли вы включить состояние в сам ресурс или выставить его через собственный ресурс.