Подтвердить что ты не робот

RESTful способ отправки команд

Как вы отправляете "команды" на сервер RESTful?

Случай использования. Мой сервер кэширует определенную информацию, чтобы он не мог читать базу данных каждый раз, когда запрашивается эта информация. Мне нужен способ отправить команду из моего клиентского приложения, чтобы сообщить серверу сбросить кеш. Вы использовали бы POST или PUT по некоторому URL-адресу, например ".../flush_cache"?

"Команда" - это не данные, для которых требуется "Передача состояния представления", если только переданное состояние не является результатом команды - "выключено", "кеш очищен" и т.д. Как правило, как REST отправляет команды на сервер?

4b9b3361

Ответ 1

Я столкнулся с такой ситуацией много в прошлом проекте. Поскольку REST хорошо... о ресурсе, не всегда ясно, как бороться с вещами, которые действительно RPC в природе.

Легкий способ обойти это - думать о нем как о бюрократической части покоя, запрос может быть самим ресурсом:

1. "Вы хотите вызвать команду на моем сервере? Сначала заполните эту форму I90292 и отправьте ее нам":

POST /bureaucracy/command-request 
Content-Type: application/x-www-form-urlencoded
Content-Length: ...
  1. "Хорошо, мы увидим, что мы можем сделать. Ваш номер корпуса - 999"

    201 Создан (или 202 принят в соответствии с комментарием Кугеля) Местонахождение/бюрократия/команда-запрос/999

  2. И затем клиент регулярно проверяет

    GET/bureaucracy/command-request/999

Надеюсь, он получит ответ вроде следующего

200 OK
<command-request>
  <number>999</number>
  ...
  <result>Success</result>
</command-request>

Конечно, если бюрократический сервис будет иметь большую заботу о клиентах, он предложит клиенту позвонить ему, когда это будет сделано, если он захочет:
"Вы хотите запустить команду на нашем сервере? Пожалуйста, заполните эту форму и отправьте ее нам. Обратите внимание, что вы можете присоединиться к своей контактной информации, чтобы мы могли позвонить вам, когда это будет сделано"

POST /bureaucracy/command-request?callback=client.com/bureaucracy/inbox 

Или как пользовательский заголовок http X-Callback: http://client.com/bureaucracy/inbox

Ответ 2

Я бы предложил следующее:

  • Создайте ресурс, который вы можете GET, который сообщит вам клиенту, как отправить команду, похожую на HTML-форму, используя POST, если есть побочные эффекты для этой команды.
  • POST для ресурса для запуска команды и возврата URI к новому ресурсу, который вы создаете во время выполнения этого запроса POST (например, http://server.example/results/00001), возможно, с статусом 204 (без содержимого) и заголовком местоположения или перенаправлением (в зависимости от того, какой клиент может понять).
  • Пусть клиент проверяет результаты на этом ресурсе с помощью GET. Вы также можете вернуть представление для этого ресурса (или чего-то подобного) в качестве объекта, возвращаемого POST перед этим.

Это зависит от вас, чтобы определить жизненный цикл ресурса результата. Это может быть кратковременно, если вам не нужно долго хранить результаты. URI может быть сконструирован, например, из UUID.

Ответ 3

В вашем случае, почему бы не сделать ресурс cache?

DELETE /cache

Если вы хотите очистить его.

POST /cache

когда вы хотите создать новый.

Или объедините предыдущие два в следующем:

DELETE /cache?autorecreate=true