我的API设计是否违反了RESTful原则？

Question

我目前（我尝试）为社交网络设计RESTful API。 但我不确定我目前的方法是否仍符合RESTful原则。 如果有些明亮的脑袋可以给我一些提示，我会很高兴的。

假设以下URI表示用户帐户的名称字段：

people/{UserID}/profile/fields/name

但是有几百个可能的领域。 所以我希望客户端创建自己的字段视图或使用预定义的视图。 假设以下URI表示包含字段“name”，“age”，“gender”的预定义字段视图：

utils/views/field-views/myFieldView

因为字段视图是一种更高的逻辑，所以我不想将对字段视图的支持混合到“people / {UserID} / profile / fields”资源中。 相反，我想做以下事情：

utils/views/field-views/myFieldView/{UserID}

另一个例子

假设我们想要执行一些数量的操作（希望这是英文的正确名称）。 我们有以下URI，而每个URI都指向一个人员列表 - 他们的朋友：

GET people/exampleUID-1/relationships/friends
GET people/exampleUID-2/relationships/friends

现在我们想知道他们的哪些朋友也是我的朋友。 所以我们这样做：

GET people/myUID/relationships/intersections/{Value-1};{Value-2}

而“{Value-1/2}”是“people / exampleUID-1 / friends”和“people / exampleUID-2 / friends”的网址编码值。 然后我们回来代表所有三个人的朋友。

虽然Leonard Richardson和Sam Ruby在他们的书“RESTful Web Services”中指出RESTful设计在某种程度上类似于“极端面向对象”的方法，但我认为我的方法是面向对象的，因此符合RESTful原则。 还是我错了？

何时不是：在小心使用时，为了避免基于查询的REST-RPC混合，这种“面向对象”的方法是否会受到鼓励？

感谢您的反馈，

饿鬼

Answer 1

我从来没有使用过REST，但我认为在'''/ people / {UserId} / profile'''获取一个配置文件资源会产生一个XML或JSON或其他东西的文档，其中包括所有的领域。 客户端然后我会忽略我不感兴趣的字段。是否比（a）在服务器上配置个性化视图或（b）提取大量请求获取每个字段要好得多？

Answer 2

嗨peta，
我自己仍在阅读RESTful Web Services ，但我建议采用与提议的方法略有不同的方法。

关于你帖子的第一部分：

utils/views/field-views/myFieldView/{UserID}

我不认为这是RESTful，因为utils不是资源。 定义自定义视图是可以的，但是这些视图应该是（imho）API的URI方案的自然组成部分。 要将上述内容合并到您的第一个URI示例中，我建议使用以下示例之一，而不是为其创建特殊视图：

people/{UserID}/profile/fields/name,age,gender/
people/{UserID}/profile/?fields=name,age,gender

后一个示例将fields视为算法的输入值。 这可能是比在URI中具有fields更好的方法，因为它不是资源本身 - 它只是对people/{UserID}/profile/的现有视图施加约束。 从技术上讲，它与分页非常相似，默认情况下您将限制视图，并允许客户端使用?page=1 ， ?page=2等浏览资源。

关于你帖子的第二部分：
这是一个更难破解的问题。

第一：在URI中有intersection会破坏你的URI方案。 它本身不是一种资源，也与friends处于同一水平，而它更适合低于一级或作为算法的输入值，即

GET people/{UserID}/relationships/friends/intersections/{Value-1};{Value-2}
GET people/{UserID}/relationships/friends/?intersections={Value-1};{Value-2}

我再次个人倾向于后者，因为与第一种情况类似，你只是限制了people/{UserID}/relationships/friends/的现有视图

其次 ，关于：

而“{Value-1/2}”是“people / exampleUID-1 / friends”和“people / exampleUID-2 / friends”的网址编码值

如果你的意思是{Value-1/2}包含所提到的GET请求的整个编码响应，那么我会避免这种情况 - 我不认为这是RESTful方式。 由于friends本身就是一种资源，您可能希望将其公开并直接访问它，即：

GET friends/{UserID-1};{UserID-2};{UserID-3}

这里需要注意的一件重要事情 - 我已经习惯了; 在前面的例子中的用户ID之间，而予使用,在fields上面的示例。 原因是两者都代表不同的运营商。 在第一种情况下，我们需要OR （ , ）以获得所有三个字段，而在上面的最后一个例子中，我们必须使用AND （ ; ）来获得交集。

使用两种类型的运算符可能会使API设计过于复杂，但最终应该提供更大的灵活性。

Answer 3

谢谢你的澄清答案。 它们正是我所要求的。 不幸的是，我没有时间从封面到封面阅读“RESTful Web Services”; 但我会尽快赶上来。 :-)

关于我的帖子的第一部分：

你是对的。 我倾向于你的第一个例子，没有字段。 我认为我根本不需要它。 （目前）为什么建议使用OR（，）代替AND（;）？ 直觉上我会使用AND运算符，因为我想要所有这三个而不仅仅是第一个存在的运算符。 （如第121页上的颜色对示例）

关于第二部分：

使用{Value-1/2}我只表示URI的url编码值 - 而不是它们的响应数据。 :)在这里，我倾向于你的第二个例子。 这里显而易见的是，在计算相交的朋友时，在引擎盖下会调用算法。 除此之外，我可能会为它添加一些进一步的操作。

饿鬼