REST: отзывчивый пользовательский интерфейс для медленных операций?

Мне нужна помощь в создании дизайна RESTful для приложения с индикатором выполнения.

Представьте себе приложение, в котором одному из ресурсов требуется много времени (более 1 минуты) для ответа на HTTP GET (в моем случае я сканирую сеть в поисках устройств). Я бы хотел, чтобы клиенты отображали индикатор выполнения, показывающий, сколько времени займет операция GET, но для того, чтобы это работало, сервер должен предоставить им оценку времени для операции.

Учитывая медленную операцию:

HTTP GET /devices

Каким RESTful способом дать оценку времени? Я не думаю, что могу использовать:

HTTP HEAD /devices

потому что HEAD должен возвращать те же значения, что и GET за вычетом тела, что (я думаю) означает, что мне придется выполнить ту же самую длительную операцию, которую я пытаюсь избежать. Любые идеи?


person Gili    schedule 05.12.2011    source источник


Ответы (2)


Если подумать, думаю, я выберу инкрементный ответ. Согласно RESTful Web Services, асинхронные операции лучше всего представлены в терминах HTTP 202. .

  1. Клиент отправляет HTTP POST /devices
  2. Сервер отвечает HTTP 202 Accepted. Location: /queues/32194532
  3. Цитата из книги:
    # P2 #
  4. Цитата https://stackoverflow.com/a/5081246/14731: задание должно возвращать 200 OK, когда запрошенный процесс все еще в ожидании. Ответ должен описывать ожидающий статус процесса.
  5. Цитата https://stackoverflow.com/a/5081246/14731: задание должно вернуть 201 Created после завершения обработки . Ответ в случае GET/PUT/POST должен содержать Местоположение запрошенного / созданного / обновленного ресурса.
  6. Цитата из книги:
    # P3 #
person Gili    schedule 05.12.2011
comment
Кажется, это лучший способ для клиента иметь возможность проверять статус по своему усмотрению (конечно, сервер должен каким-то образом обновить этот ресурс. Первым ответом на этот вопрос, вероятно, также должен быть POST. ( stackoverflow.com/a/8388956/525) - person pc1oad1etter; 05.12.2011

Может быть, просто создать отдельный ресурс "прогресс"?

GET /progress/foo
person Matt Ball    schedule 05.12.2011
comment
Я бы не стал этого делать, потому что это не ресурс - это подделка. - person John Saunders; 05.12.2011
comment
Не настоящие? Итак, когда вы получаете / person / 1, это «настоящий» человек? - person pc1oad1etter; 05.12.2011
comment
Согласен - можете сделать это отдельным ресурсом. Например, если ваш ресурс с информацией о стоимости запроса находится в / devices / queryinfo, тогда .... Вы можете добавить заголовок ссылки в / devices указывающие / устройства / queryinfo. Затем клиенты могут получить ссылку из результата HEAD и проверить, насколько дорогостоящим может быть действие, прежде чем его предпринять. - person pc1oad1etter; 05.12.2011