根据 REST 标准，这些 URL 中的哪一个是最好的？

Question

我正在尝试找出设计我的 rest api 的 URL 的最佳/正确方法，但我在 company 资源之间感到困惑。

这是位于http://localhost:8085/api/v1/company/1 的company 资源。这将从company 表中返回一些基本数据。

到目前为止还好。但是现在公司可以有两种类型：1.机械 2.其他。每个人在 DB 中都有各自的表，1:1 与 company 表的关系。要获取有关公司的更多详细信息，我需要从某个 API 端点公开另外两个表。

所以，我对这里的三个 URL 感到困惑：

1. http://localhost:8085/api/v1/company/1?type=mechanical
2. http://localhost:8085/api/v1/company/1/mechanical
3. http://localhost:8085/api/v1/company/mechanical/1

我拒绝选项 1 的原因之一是我在 SO 上找到的，即无法缓存具有参数的路径。 Rest Standard: Path parameters or Request parameters

我主要在 2 和 3 之间感到困惑？正确的方法是什么？

您可能会问一个问题，为什么我不提供来自http://localhost:8085/api/v1/company/1 的完整公司信息？那是因为我想利用延迟加载。公司的详细信息可能需要更多时间才能获取，因此我将内容分开。

Answer 1

我正在尝试找出设计我的 rest api 的 URL 的最佳/正确方法，但我在公司资源之间感到困惑。

REST 不关心您的 URL 使用什么拼写，只要它们符合 RFC 3986。 URI 是标识符，不要求标识符的拼写与其语义有任何关系。

人类可读的 URI 很像人类可读的变量名 - 不是必需的，但在涉及人的地方肯定很方便。所以拼写应该主要按照当地的惯例来选择。

要获取有关公司的更多详细信息，我需要从某个 API 端点公开另外两个表。

REST 的部分意义在于您的资源模型可能不会与您的数据模型紧密耦合。 “在互联网上，没有人知道你是一只狗”。您当然可以为关系模式的每个部分创建资源。

请注意，没有经验的人会保证结果在长期内是可行的。

我拒绝选项 1 的原因之一是我在 SO 上找到的，即无法缓存具有参数的路径。

我几乎可以肯定这是一个非常糟糕的答案，因此对给定设计的支持很差。但同样，REST 并不关心拼写。

http://localhost:8085/api/v1/company/1?type=mechanical
http://localhost:8085/api/v1/company/1/mechanical
http://localhost:8085/api/v1/company/mechanical/1

所有这些都很好。

选择一种路径段顺序而不是另一种顺序的一个原因是利用点段和relative resolution；也就是说，如果我们取上面的URI，并尝试解析relative-path-reference ..会发生什么情况@

http://localhost:8085/api/v1/company
http://localhost:8085/api/v1/company/1
http://localhost:8085/api/v1/company/mechanical

鉴于您在此处描述的内容，选项 #2 看起来比它的表亲更有用。

如果相对分辨率不是一个重要的用例，那么您可以考虑使用新的词干

http://localhost:8085/api/v1/mechanical-company/1

首先应该是 /companies

仅当这是本地拼写约定时。

/company/1
/companies/1
/c5y/1
/c6s/1
/compagnie/1
/c5be6eed-3df2-4987-aceb-1b2f8909cb85/1
/purpleMonkeyDishwasher/1

任何机器都不关心您使用这些拼写中的哪一个。