我们有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需要在其末端放置逻辑以调用正确的端点并填充因变量。
所以我的第一个问题是，资源可以具有可选属性吗？
对于正在考虑的情况，为什么分开的端点有意义？
答案 0 :(得分：0)
我的观点：设计REST api（所有场景使用单个URL或基于场景使用单独的URL）时没有硬性规定。如果确实不需要基于场景的URL，则通常不建议使用，因为如果将来您的业务场景增加，它将以更多的URL结尾。
如果X，Y，Z的功能完全不同（无论哪种情况），请尝试使用不同的URL。如果功能相同，只是reviewDecision参数不同，那么我建议您在单个URL中使用path param（ /host/controller/{reviewDecision}/），然后在正文中添加其他内容。
答案 1 :(得分：0)
您可以使用一点HATEOAS并将decision与vars分开。
1.在/review-xyz-result上发帖，您会得到：
{
"reviewDecision":"X" (OR) "Z",
"variables-href":""
}
OR
{
"reviewDecision":"Y",
"variables-href":"/review-xyz-result/{idOfResource}" OR
"variables-href":"/review-xyz-result/var"
}
然后您通过/review-xyz-result/{idOfResource}或其他方式调用POST