Моделирование ресурсов REST для решения на основе результатов - PullRequest
Новая
       10

Моделирование ресурсов REST для решения на основе результатов

0 голосов
/ 26 апреля 2019

У нас есть 2 системы A и B. Система A выполняет некоторую задачу проверки вручную, и одна из этих задач проверки завершена, система A должна делиться результатами проверки с системой B. Система B не должна опрашивать систему Aдля результата обзора.

При разработке API для этого запроса мы создали ресурс, который выглядит следующим образом:

POST / review-xyz-result / 

{
 "var1": "string",
 "var2": "string",
 "var3": "string",
 "reviewDecision": "X, Y, Z"
}

Когдарезультат Y, var 1, var2 и var 3 будут заполнены.Для решений X и Z переменные будут пустыми. Результат проверки может иметь только одно решение, т.е.или X, или Y, или Z.

Каков наилучший способ моделирования такого ресурса .?

Некоторые мнения в нашей группе разработчиков говорят, что позволяет разбить один API на 3 конечных точки один длякаждое решение.Почему-то я не чувствую, что это правильный путь.Системе А потребуется поставить логику на своем конце, чтобы вызвать правильную конечную точку и заполнить зависимые переменные.

Итак, мой первый вопрос: может ли ресурс иметь дополнительные атрибуты?

Для рассматриваемого случая, почему отдельные конечные точки имеют какой-либо смысл?

Ответы [ 2 ]

0 голосов
/ 26 апреля 2019

Вы можете использовать немного HATEOAS и разделить decision от vars.

1. ПОСТАВЬТЕ на /review-xyz-result и получите: 

{
"reviewDecision":"X" (OR) "Z",
"variables-href":""
}

ИЛИ 

{
"reviewDecision":"Y",
"variables-href":"/review-xyz-result/{idOfResource}" OR
"variables-href":"/review-xyz-result/var"
}

А затем вы вызываете POST на /review-xyz-result/{idOfResource} ИЛИ и т.д.

0 голосов
/ 26 апреля 2019

Моя перспектива: при разработке REST API нет строгих правил (один URL для всех сценариев или отдельный URL для сценариев на основе). В большинстве случаев URL-адреса на основе сценариев не очень рекомендуются, если на самом деле это не требуется, потому что в конечном итоге их будет больше, если ваши бизнес-сценарии будут расширяться.

Если ваша функциональность X, Y, Z совершенно разная, независимо от сценариев, попробуйте ее для разных URL. Если функциональность одинакова, то только параметр reviewDecision отличается, тогда я предлагаю вам перейти с параметром пути ( /host/controller/{reviewDecision}/) в одном URL-адресе, а затем добавить другое содержимое в тело.

...