我目前(我尝试)为社交网络设计一个 RESTful API。但我不确定我目前的做法是否仍然符合 RESTful 原则。如果有聪明的头脑可以给我一些提示，我会很高兴。
假设以下 URI 表示用户帐户的名称字段:
people/{UserID}/profile/fields/name
但是有近百个可能的领域。所以我希望客户创建自己的字段 View 或使用预定义的字段 View 。假设以下 URI 表示一个预定义的字段 View ，其中包括字段“姓名”、“年龄”、“性别”:
utils/views/field-views/myFieldView
并且由于字段 View 是一种更高的逻辑，我不想将对字段 View 的支持混合到“people/{UserID}/profile/fields”资源中。相反，我想执行以下操作:
utils/views/field-views/myFieldView/{UserID}
另一个例子
假设我们要执行一些数量操作(希望这是它的英文正确名称)。我们有以下 URI，其中每个 URI 都指向一个人列表——他们的 friend :
GET people/exampleUID-1/relationships/friends
GET people/exampleUID-2/relationships/friends
现在我们想找出他们的哪些 friend 也是我的 friend 。所以我们这样做:
GET people/myUID/relationships/intersections/{Value-1};{Value-2}
而“{Value-1/2}”是“people/exampleUID-1/friends”和“people/exampleUID-2/friends”的 url 编码值。然后我们得到所有三个人的 friend 的代表。
尽管 Leonard Richardson 和 Sam Ruby 在他们的书“RESTful Web 服务”中指出 RESTful 设计在某种程度上类似于“极端面向对象”的方法，但我认为我的方法是面向对象的，因此符合 RESTful 原则。还是我错了？
何时不:这种“面向对象”的方法在谨慎使用时是否普遍受到鼓励，以避免基于查询的 REST-RPC 混合？
提前感谢您的反馈，
佩塔
最佳答案
我从来没有使用过 REST，但我假设在 '''/people/{UserId}/profile''' 获取配置文件资源会产生一个 XML 或 JSON 格式的文档，包括所有字段。客户端然后我会忽略我不感兴趣的字段。这不是比必须 (a) 在服务器上配置个性化 View 或 (b) 发出大量请求来获取每个字段更好吗？
关于api - 我的 API 设计是否违反了 RESTful 原则？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2530423/