Сценарий API RESTful

Question

Я спрашиваю о сценарии службы RESTful в конкретном случае. Предположим, что это служба удаления файлов. Затем пользователи отправляют заказ, а затем через определенный промежуток времени (1-10 мин.) Файл pdf готов к загрузке. Так основы я пришел с:

• пользователя отправляет заказ, используя метод GET для веба-сервиса (редактирование: ИЛИ POST)
• вебсервиса возвращает orderid через json или xml

• некоторых фон и человеческий процесс занимает место (1 - 10 мин)

• пользователь проверяет статус заказа, передавая orderid к WebService

• , если заказ будет готов тогда statusCode и pdfLink возвращаются пользователь
• иначе statusCode возвращается только (то есть еще обрабатывающий, не удались, и т.д.)

Теперь вопрос об этом сценарии является то, что, как часто пользователь (другой сайт) должен попытаться получить статус одного конкретного заказа?

Нужно ли нам создавать двойные веб-сервисы? как:

• сервер А представляет приказ B
• B Informes А что заказ готов получить
• запрашивает B для pdfLink
• А transferes файл в формате PDF с сервера B в A

Answer 1

Когда сервер A отправляет заказ B, он также может указать URL-адрес, по которому он ожидает вызова, если заказ будет готов. Таким образом, услуга B не обязательно должна знать специфику обслуживания A. Он просто вызывает URL-адрес, указанный службой A.

Служба ответа B, предоставляемая службе A, также может содержать URL-адрес, где скачать заказ.

Это предотвращает опрос от сервера А на сервер Б, что значительно снижает нагрузку на службы В.