REST API：资源层次结构和多个 URI

Question

我使用银行数据库，其结构如下：

Table      Primary Key   Unique Keys          Foreign Keys
-------------------------------------------------------------
BANK       ID            BIC           
CUSTOMER   ID            CUSTNO, PASS, CARD   BANK
ACCOUNT    ID            IBAN                 BANK, CUSTOMER

我想设计一个干净的 REST API，但我运行遇到以下问题：

我应该将资源置于层次结构中，还是扁平化？层次结构的问题可能是客户端只知道ACCOUNT ID，但不知道CUSTOMER ID，那么他应该如何获取资源？

/banks/{id}/customers/{id}/accounts{id}
or
/banks/{id}
/customers/{id}
/accounts{id}

每个table中的主键是数据库ID。它是一个内部ID，没有业务意义。将其用作资源的默认URI是否正确？
每个对象都有自己的一组唯一键。例如，CUSTOMER可以通过他的CUSTNO、PASS或CARD来识别。每个客户端只有这些密钥的一个子集。我应该为每个键定义一个子资源还是提供一个查找服务来返回正确的 URI？

/customers/id/{id}
/customers/custno/{custno}
/customers/pass/{pass}
/customers/card/{card}
or
/lookup/customer?keyType=card&keyValue=AB-303555
 (gives back customer {id})

我在问什么是真正的 RESTful 方法，什么是最佳实践。我还没有找到合适的答案。

Answer 1

I am asking what is the truly RESTful way, what is best practice.

REST 不关心您使用什么拼写作为标识符。

/ef726381-dd43-4017-9778-83cee2bbbd93

是一个完美的 RESTful URI，适用于任何用例。

除了一些纯粹的机械问题之外，通用消费者将 URI 视为单个不透明单元。没有消费者从 URI 中提取语义信息的概念——这意味着编码到标识符中的任何信息均由服务器自行决定并仅供其使用。

对于客户端已知的信息需要包含在请求的目标 uri 中的情况，我们有 URI Templates，这是 GET 形式的一种概括 HTML。所以 a 思考问题的方法是考虑客户拥有哪些信息，以及他们如何将这些信息放入表格中。

HTML 的表单处理规则非常有限——一般 URI 模板的约束较少。

/customers/id/{id}
/customers/custno/{custno}
/customers/pass/{pass}
/customers/card/{card}

让多个资源共享公共信息在 REST 中很正常——您的资源模型不是您的数据模型。所以这可能没问题。甚至可以拥有共享表示的多个资源。您可以让它们独立，或者您可以让它们共享 Content-Location 或 canonical link 关系，或者您可以简单地将这些资源重定向到规范资源。

一切都很好。

So you mean if a UUID can be a valid URI, then a table autonumber key can be too?

是的，完全正确。

请注意，如果您希望 URI 的生命周期超过当前实现的生命周期，那么您需要在设计标识符时考虑到该约束。参见 Cool URIs Don't Change。

客户不关心 URI 是什么，他们只希望 link 在需要时再次工作。

REST API：资源层次结构和多个 URI

REST API: Resource hierarchy and multiple URI

rest

restful-url