REST资源相关数据

Question

我已经创建了一个RESTAPI，我想我遇到了RESTful问题。

它与以下问题有关：

• 检索相关数据

我有一个叫做“案例”的资源。案例还包含相关数据，如用户和消息。问题是我想从案例中获取相关的查询用户和消息数据，但我不确定URI设计。也有不同类型的相关/计算数据。这些相关数据应用于创建数据可视化。

我如何获取案例/用户/消息是RESTful的：

http://example.com/cases (and with id for a single case)
http://example.com/cases/{id}/users (same idea as above)
http://example.com/cases/{id}/messages (same idea as above)

我创建相关资源的第一个想法是（我认为URI看起来不对，它可能有点RPC？）

相关数据1：

http://example.com/cases/{id}/analysis/messages-network-traffic

{
    "sender": "an user jack", 
    "receiver": "an user steph", 
    "amount_messages": 51
}, 
{
    "sender": "an user test", 
    "receiver": "an user test4", 
    "amount_messages": 3
}
...

相关数据2：

http://example.com/cases/{id}/analysis/messages-timeline?receiver=testuser1&sender=testuser2
{
    "amount_messages": 24, 
    "timestamp": 1387321576
}, 
{
    "amount_messages": 50, 
    "timestamp": 1387321576
}
...

URI设计的这些想法是否正确（我认为这是一种RPC），或者我应该怎么做？因为我看不出有任何理由创建类似于相关问题的报告资源。这些数据只是对现有资源的计算。

提前谢谢你。

Answer 1

您的这些URL看起来不错：

http://example.com/cases（单个案例的id）

http://example.com/cases/{id}/用户（同上）

http://example.com/cases/{id}/消息（思路同上）

就您的相关数据以及如何查询它们而言，我建议您首先应该决定返回数据结构，考虑到在这两种情况下您都返回“消息”（尽管包含一些不同的数据）。我要做的是，我将为两个相关资源urls提供一个通用的json结构，类似于

{“sender”：“用户测试”，

“receiver”：“用户测试4”，

“amount\u消息”：3，

“时间戳”：12312421424}

我的资源URL看起来有点像这样：

获取http://example.com/cases/{id}/消息

获取http://example.com/cases/{id}/消息？接收器=testuser1

我不明白url中“/分析”的原因。它有点多余（当然除非有非常具体的原因）。将使用您的apis的客户端希望返回数据是通用的，尤其是当他们尝试对同一资源进行过滤查询时。在您的情况下，我们要么列出“消息流量”（我将其称为列出“所有消息”），要么列出“消息流量”，其中发送者是FOO，接收者是BAR（我将其称为按发送者和接收者信息过滤“所有消息”数据。

保持返回数据模型的一致性有助于客户机开发人员生成POJO（在java land中）和/或一致的数据模型。

我希望这有帮助！祝你好运

Answer 2

我知道你已经接受了一个答案，但是我觉得两个答案都有点不对劲。

为您的问题设计一个RESTful解决方案与URL的外观无关，而与提供指向关系的链接作为表示本身的一部分有关。您需要使用允许您表达这些链接关系的媒体类型。HTML可以，但XML和JSON本身不能。我个人最喜欢的是HAL over JSON。

下面是使用HAL over JSON的示例：

请求：

GET /cases/1 HTTP/1.1
Host: example.com

答复：

HTTP/1.1 200 OK
Content-Type: application/hal+json;profile=vnd/com.example-v1

{
  _links: {
    "self": {
      href: "/cases/1"
    },
    "users": {
      href: "/cases/1/users"
    },
    "newest_user": {
      href: "/users/371629"
    },
    "messages": {
      href: "/cases/1/messages"
    }
  },
  "case-name": "Foo",
  "case-created-date": "2013-11-01"
  ..... <more case attributes here>
} 

请注意，指向“newest_user”的链接指向单个用户，并且引用是不透明的（也就是说，如果没有服务器给你这个值，你就无法猜测它）。从技术上讲，在这样的架构中，所有URL都应该被视为不透明的（即使其中一些是人类可读的，并且以资源/id/子资源的方式组织）。

因此，当您编写API指南时，您可以指定每个链接关系的含义（在本例中是用户、newest_user和消息），并且客户端将知道他们在跟踪每个链接时得到了什么，而不管URL看起来像什么。

顺便说一句，这种类型的信息在REST世界中被称为超媒体作为应用程序状态的引擎，也称为“超媒体约束”这是REST统一接口约束的要求。

Answer 3

仅仅因为您可以提供一个实现并不意味着这样做是有意义的。例如，在http://example.com/cases上执行PUT可能没有意义。您可以将PUT改为http://example.com/cases/1或类似的东西。一个特定的实例。同样，在http://example.com/cases/1上执行POST可能也没有意义。由您决定应用程序的语义学，使用REST的语法。

我看不出您的REST设计有什么问题-只要endpoint以“声明性”的方式命名，就可以了。如果他们有一些“程序”名称，比如：<代码>http://example.com/cases/goDoSomething，这将是一个值得关注的问题。

记住，您的REST设计是您的客户用来与您的服务对话的“语言”，所以请设计该语言，以便通信是声明性的，并且适合手头的任务。为用户设计，而不是在后端为您自己的方便。