Ответ с неполным ресурсом на асинхронный запрос в REST API

Question

Создание ресурса в асинхронном API REST. Допустимо ли, если мой сервер отвечает неполным ресурсом с индикатором состояния вместо возврата временного ресурса ?

---

В качестве примера, скажем, у меня есть служба, которая нотариально заверяет сообщения, добавляя их в блокчейн, чтобы позже доказать их существование (например, «Доказательство существования»).

Выполнение занимаетв то время как это хорошая идея сделать асинхронным.

Пользователь отправляет POST /messages с полезной нагрузкой:

{
    "message" : "Hello SO friends!"
}

Затем сервер отвечает 202 Accepted телом:

{
    "id" : 1999283,
    "message" : "Hello SO friends!",
    "status" : "pending",
    "block" : null,
    "timestamp" : null
}

И заголовок Location: /messages/1999283

Ресурс, изображенный выше, является неполным , так как он все еще не имеет блока и метки времени и имеет "pending "status.

Пользователь будет опрашивать /messages/1999283 и получит 200 OK с тем же json, что и выше, в теле, пока сервер ожидает его добавления в блок.

Через несколько минут пользователь снова начнет опрос и получит 200 OK вместе с complete resource:

{
    "id" : 1999283,
    "message" : "Hello SO Friends!",
    "status" : "completed",
    "block" : 10029,
    "timestamp" : "20181215T204012Z"
}

Answer 1

Альтернативный взгляд на это, возможно, это не временный ресурс.Возможно, это обычный ресурс с незавершенным состоянием.

Если вы считаете, что это реальный ресурс, который позже изменит состояния, вам не нужно особо задумываться об использовании 202 Accepted.Транзакция, которую вы создаете, «существует», просто она еще не обработана.

Answer 2

По моему мнению, метод, который вы используете, является правильным.Основное назначение статуса 202 Accepted состоит в том, что «запрос принят, и сервер его обработает».

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

{
    "id" : 1999283,
    "message" : "Hello SO friends!",
    "status" : "pending",
    "block" : null,
    "timestamp" : null,
    "estimatedTime" : 30 ////
}

Это будет иметь 2 преимущества:

1) Пользователь будет знать, сколько времени потребуется для обработки запроса, и не будет запрашивать столько времени, чтобы сэкономить несколько обращений на сервер.

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

Помимо этогодругой процесс выглядит очень аккуратно.