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，但我遇到了以下问题。

1. 我应该把资源放在一个层次结构中，还是扁平化？层次结构的问题可能是客户端只知道了 ACCOUNT ID但不知道 CUSTOMER ID，那么他该如何获取资源呢？

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

2. 每个表的主键是数据库的 ID. 它是一个内部ID，没有任何商业意义。使用它作为资源的默认URI是否正确？

3. 每个对象都有自己的一组唯一键。例如： 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

我想问的是什么是真正的REST方式，什么是最佳实践。

REST并不关心你的标识符使用什么拼写。

/ef726381-dd43-4017-9778-83cee2bbbd93

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

除了一些纯粹的机械性问题外，一般的消费者会把URI当作一个单一的不透明单位。 没有消费者从URI中提取语义信息的概念--这意味着任何编码到标识符中的信息都是由服务器自行决定的，并且只为其使用。

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

HTML的表单处理规则是相当有局限性的--一般的URI模板的限制较少。

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

在REST中，拥有多个资源共享共同信息是正常的--你的资源模型不是你的数据模型。 所以这可能是好的。 甚至可以让多个资源共享表示方式。 你可以让它们独立存在，也可以让它们共享一个 Content-Location或a 正统 链接关系，或者你可以简单地让这些资源重定向到规范资源。

这都很好。

所以你的意思是，如果一个UUID可以是一个有效的URI，那么一个表自数键也可以是？

是的，没错。

需要注意的是，如果你希望URI的寿命超过你当前实现的寿命，那么你需要在设计标识符时考虑到这个约束。 请看 酷炫的URI不会改变.

客户并不关心URI是什么，他们只是希望链接在他们需要的时候能够再次使用。