Как RESTFul представляет URL-адреса при создании одного и того же объекта с использованием одной структуры URL-адреса, но может вызывать различные методы сервера? - PullRequest
Новая
       11

Как RESTFul представляет URL-адреса при создании одного и того же объекта с использованием одной структуры URL-адреса, но может вызывать различные методы сервера?

0 голосов
/ 04 февраля 2020

Допустим, у меня есть конечная точка для создания объекта, выполнение которого занимает некоторое время и имеет следующую структуру URL: /api/v1/objects.

Бизнес-правила предписывают, чтобы потребители API могли вызывать эту конечную точку синхронно или асинхронно в сервер. Результатом этого вызова в конце концов является создание одного и того же объекта, но ответ на отправку конечной точки различается между двумя в зависимости от того, вызывается ли она синхронно или асинхронно (т. Е. Если вызов выполняется асинхронно, потребитель может получить идентификатор без гарантии, будет ли объект создан или нет, при одновременном вызове конечной точки всегда будет создаваться объект и возвращаться в ответе.)

Прямо сейчас у меня есть эта структура для различения синхронного и Асинхронные вызовы API:

  • POST /api/v1/objects - для синхронного создания объекта.
  • POST /api/v1/objects?async=true - для асинхронного создания объекта.

Это подход правильный и соответствует принципам RESTFul?

1 Ответ

0 голосов
/ 04 февраля 2020

Если вы посмотрите на RF C для HTTP (см. https://tools.ietf.org/html/rfc7231#section -5.1.1 ), вы увидите заголовок Expect, который в основном определяет, какое поведение клиент ожидает от сервер.

Учитывая, что у вас могут быть разные 20* ответы (200, 201, 202, 204), вы можете использовать это, чтобы определить, должно ли это быть asyn c или нет.

При быстром поиске в Google появляется этот пример (который я копирую и вставляю здесь для дальнейшего использования):

Клиент может запросить сервер изменить его асинхронное поведение с помощью следующих заголовков «Expect»:

  • «Expect: 200-ok / 201-creation / 204-no-content» отключает все асинхронные функции. Сервер может вернуть «417 Expectation Failed», если он не готов ждать завершения операции.
  • «Ожидается: 202-принято» явно запрашивать асинхронный ответ. Сервер может вернуть «417 Expectation Failed», если он не желает выполнять запрос асинхронно. Если ожидание не предусмотрено, клиент должен быть готов принять статус 202 «Принят» для любого запроса, кроме GET.
...