具有多个主键的资源的 REST API URI答案

【问题标题】：REST API URI for resource with multiple primary keys具有多个主键的资源的 REST API URI
【发布时间】：2016-06-04 09:49:36
【问题描述】：

我正在为我的项目开发一个通用 REST API，我想知道当我有一个具有 2 个或更多主键的表/资源时该怎么办。

例如，假设我有一个名为“question”的表，其中包含两个主键（日期和类型），并且我需要创建资源 REST URI。遵循标准架构 api/{resource}/{id} 的最佳方法是什么？

也许是这样的：api/question/{:date},{:type}？最好的方法是什么？

谢谢。

【问题讨论】：

【解决方案1】：

我认为你所说的多个主键是一个复合键。对吧？

也许，最适合您的选择是：

api/questions/date/{:date}/type/{:type}

对于您的情况，将其作为 http 资源阅读更为自然，即使在您的应用程序中使用 api/question/date/{:date} 没有意义。

另一种选择是：

api/questions/{:date}/{type}/

【讨论】：

好方法。
如果您的实体有另一个实体 id 作为复合 id 怎么办。表达整个层次结构？我们只是为了遵循层次结构建议而放置琐事，因为我们实际上只需要 topicId 和 questionId 来检索问题 trivia/topic/topicId/question/questionId

【解决方案2】：

你走在正确的道路上，我认为你绝对应该在资源 url 中同时包含日期和类型，如果这是你唯一可以识别它的唯一方法

api/question/{date}_{type}

【讨论】：

【解决方案3】：

这是何时使用蛞蝓的一个很好的例子。这个对 What is a slug 的回答很好地说明了如何在 api 设计中使用复合主键。

这样，您就有了几个选择。哪个是最好的将是一个意见问题，什么适合您的需求。

同样的模式也可以应用于以下。

【讨论】：

【解决方案4】：

我认为一个资源有两个主键不是一个好主意。 REST 很大程度上依赖于resources 及其表示形式。

如果您遇到一个资源有两个标识符的情况 - 然后重新设计您的应用程序（可以通过在将其映射到其他标识符后在后端创建另一个键）并将这些多个键添加为资源中的属性.

如果您想创建真正世界级的 REST API，想法是“保持简单”。

奖励：您不需要向客户/开发人员教授一些额外的东西来了解您使用 API 所做的一些花哨的事情。

【讨论】：