Question

我正在基于BISDM的修改版本为多个数据库实体创建RESTful服务。其中一些实体具有关联的查找表，如下所示：

Snippet of modified BISDM schema

查找表与一个且只有一个表相关联。此外，客户端应用程序将使用查找表为其关联实体表的可编辑字段填充下拉列表，树视图和组合框。

查找值/表是应该获取自己的URI，还是应该与它们关联的父项“共享”？每个人的利弊是什么？

Option 1:
   /Entities/Spaces/SpaceCategories/
Option 2:
   /Lookups/SpaceCategories/

Answer 1

URI也可能是不可读的，urlsafe，编码二进制文件。你如何构建它们并不重要。这与REST无关。

Answer 2

在RESTful系统中，构建URL的方式并不像您识别的资源和您提供的名称那么重要。

根据您的展示，您看起来有三种资源：

您为这些资源提供的URI在很大程度上取决于品味。例如，REST中没有任何内容阻止您定义一个URI系统，在该系统中，每个资源（无论其类型如何）都被分配了哈希代码并通过以下方式访问：

某些框架（如Rails）可以方便地使用URI中资源的名称创建嵌套资源URI层次结构。但这只是您的应用程序可以遵循的约定。

REST定义了许多约束，其中最难以理解的是应用程序为hypertext-driven。此约束的一个优点是它可以促进您的应用与其客户之间的松散耦合。

这个想法是当客户端通过URI请求资源时，合同的一部分是客户端只能根据资源表示中提供的链接选择另一个URI。这与您使用浏览器关注网页中的链接的方式没有什么不同。

这与RPC样式的方法形成对比，在该方法中，URI模板被发布并变为硬连线到客户端代码中。

如果在将来的某个时候您决定嵌套URI比平面URI工作得更好，您可以更改您的URI方案，它不会破坏任何客户端代码。您甚至可以将资源移动到完全不同的域，或者将协议从HTTP更改为HTTPS或FTP。您的URI模板尚未发布，因此不应该针对它们编写客户端代码。

相反，您的应用程序只是开始提供新链接，并且客户端开始关注这些链接。

当我最初接触它时，我发现所有这些都令人头脑麻木抽象（我仍然感觉自己的方式）。说明这个概念的例子并不多，但对于其中一个，请查看Sun Cloud API。

Answer 3

虽然我同意 Wahnfrieden ，但是URL的构造与REST无关（只要它们唯一地标识资源），RESTful接口的一个未说出口的目标似乎是人类可理解性。因此，拥有至少可以了解数据访问方式的URL是有意义的。

那么，您的数据是如何访问的？查找表是在多个“父”表之间共享的吗？这表明你的第二种方法。它们是针对单亲的吗？这将表明第一个。

但是接下来的问题是你为什么要首先暴露查找表。如果它是用于客户端验证，那么第二种方法更有意义，因为它将“辅助”数据与“真实”数据进行分区（尽管我可能会给它一个指示与父级关系的URL）。 / p>

另一方面，如果您希望客户端使用查找表自己进行查找......请不要这样做。是的，保持数据规范化很好，但是（1）如果你在已经填写的查询中返回数据，它会更有用，（2）如果不这样做，你将会增加服务器上的流量。 / p>