HTTP-метод для представления действий «запусти и забудь» в сервисе RESTful

Question

Если подумать о REST, то относительно легко сопоставить методы HTTP с действиями CRUD: POST для создания, GET для чтения и т. Д. Но как насчет действий «запустить и забыть»? Какой HTTP-метод лучше всего представляет действие «забыл и забыл», например, запускает пакетное задание (при котором ответ не возвращается отправителю)?

На ум приходит POST, но я думаю, что GET также является подходящим методом, потому что в 99% случаев вы предоставляете только несколько параметров для этих типов действий. Как вы думаете?

Answer 1

POST мог бы прийти на ум, но я думаю, что GET - более подходящий метод, потому что в 99% случаев вы предоставляете только несколько параметров для этих типов действий.Как вы думаете?

Внешнее состояние

Я думаю, что количество используемых вами параметров не имеет ничего общего с используемым глаголом.Ключевой вопрос заключается в том, меняете ли вы внешне видимое состояние?

Ресурсы BatchJob

В вашем примере, если пакетное задание не влияет на внешне видимое состояние какого-либо объекта, вы можете реализовать его как пакетное задание,Однако вы можете смоделировать пакетное задание как ресурс со связанным контейнером ресурсов.

Вы можете использовать Post для создания нового ресурса BatchJob и позволить пользователю выполнить GET, чтобы увидеть ход выполнения задания до настоящего времени.,Вы можете выполнить GET для контейнера ресурсов, чтобы вывести список всех запущенных пакетных заданий, возможно, вызвав DELETE, чтобы уничтожить одно из них.

Answer 2

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

Одна мысль, не может ли действие на самом деле вернуть ответ:

a).Нет, сэр, это невыполнимая просьба, мы не можем начать вашу работу.б).Понятно, ваш справочник о работе - 93.

Answer 3

Вы должны использовать POST, если ваш запрос изменяет данные, и GET, если он только читает их.

Поскольку ваш запрос "запустить и забыть", я полагаю, что он изменяет данные, поэтому используйте POST.

Answer 4

Я возвращаю этот вопрос из мертвых, чтобы предложить другую точку зрения.

Теперь, когда CORS распространен, выбор между использованием GET или POST становится вопросом, хотите ли вы, чтобы кто-либо, кто знает ваш URI API, мог запускать пакетное задание (GET), или если вы хотите ограничить источник запроса, чтобы предотвратить запуск задания любым Джо с компьютером (POST).

Answer 5

Если вы обеспокоены этим уровнем, возможно, HEAD - это тот метод HTTP, который вам нужен; это идентично GET с условием, что тело ответа пусто. Это звучит для меня точно на то, что вы просите?