具有两个独立主键的实体的 RESTful API 行为

Posted 2023-03-31

【中文标题】具有两个独立主键的实体的 RESTful API 行为

【英文标题】：RESTful API behavior for entitys with two independent primary keys

【发布时间】：2014-11-07 10:46:03

【问题描述】：

我有以下实体：

<car>
    <carID>7</carID>
    <...>...</...>
    <externalCarID>23890212</externalCarID>
</car>

现在的问题是carID 和externalCarID 都是独立的主键，供不同系统使用/用于不同系统，API 客户端应该可以使用carID xor 访问car 实体externalCarID。

两个键都是整数，它们不使用不相交的集合：

carID(7) != externalCarID(7)

我想到了以下解决方案：

使用/restapi/car/7 和/restapi/externalcar/23890212 访问它 使用参数，例如喜欢/restapi/car/7?type=regular 和/restapi/car/23890212?type=ext 在标题某处发送信息 - 但在哪里？

一些如何处理这个问题的提示或对我的解决方案的反馈，最好是参考 REST / HTTP 规范，会很棒！

关于主键的背景：

假设我们的发票系统需要carID，而我们的母公司控制系统需要externalCarID。我根本不喜欢这样，但它是一个正在运行的系统，我现在无法更改它。

【参考方案1】：

我建议您选择一个 ID 作为“真正的主 ID”，并按照建议访问它：

/restapi/car/7

如果您控制其中一个 ID，那么我建议将其用作“真正的主要”。

另一个 ID，即使它是唯一标识符，也应该使用查询参数访问：

/restapi/car?extid=23384

有一些类似的问题可能会有所帮助：

REST API DESIGN - Getting a resource through REST with different parameters but same url pattern

Different RESTful representations of the same resource

要考虑的最后一件事是将“extid”的 URL 重定向到该资源的规范 URL。

【讨论】：

麻烦的是一个查询参数通常被认为是一个过滤器。因此 /restapi/car/7 将返回一个带有 200/404 响应的项目​​，具体取决于密钥是否存在。但是，/restapi/car?extid=23384 将始终返回带有集合的 200 响应。在这种情况下，由于查询参数是唯一键，因此集合将包含单个项目，如果不存在匹配记录则为空。

【参考方案2】：

在提供的三个选项中，第一个对我来说看起来最好。特别是考虑到每个外部系统将只使用一个基本 URL。对于第二个选项，您也可以使用看起来更干净的/restapi/car/?extid=23384。在第三种情况下，我认为标头用于元数据，因此使用它们不是用于管理表示上下文，而是完全更改 url 返回的对象不是一个干净的选择。就个人而言，根据您的性能要求，我要么选择第一个解决方案，要么选择常规的 /rastapi/car/7 id 我会考虑我系统中的主要解决方案，restapi/car/?extid=1234 作为辅助唯一键，可能会将 GET 重定向到规范 url ，如果它不会对性能造成太大影响。