基于决策的结果的REST资源建模

Question

我们有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个端点。不管怎样，我觉得这不是正确的做法。系统A需要在其末尾放置逻辑以调用正确的端点并填充因变量。

所以我的第一个问题是，资源是否具有可选属性？

对于正在考虑的案例，为什么单独的端点会有意义？

Answer 1

我的观点：设计REST api时没有硬规则（所有场景的单个URL或基于场景的单独URL）。如果不是真的需要，大多数情况下基于场景的URL都没有太多建议，因为如果您的业务场景在未来增加，它将会有更多的URL。

如果您的X，Y，Z的功能完全不同，无论情况如何，请尝试使用不同的URL。如果功能相同，只有reviewDecision参数不同，那么我建议您在单个URL中使用路径参数（ /host/controller/{reviewDecision}/），然后在正文中添加其他内容。

Answer 2

你可以使用一点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"
}

然后你在/review-xyz-result/{idOfResource}等上调用POST