用于查找平均值的REST接口

假设我想创建一个REST接口来查找数字列表的平均值。假设每次提交一个数字。你会怎么做

发帖

如果这是第一个数字，将返回哈希

发帖

找到平均值

删除，因为我们不再需要它

---

这样做对吗？有什么建议吗？

将数字列表视为资源更有意义。假设每个列表的资源URL是

/list/{id}

，其中

{id}

是列表id的占位符。然后：

POST/list

创建一个新列表，服务器生成一个列表ID（或“哈希”），并在响应的

位置
标题中指定
/list/{ID}
URL

POST/list/{id}

在列表中添加一个数字

GET/list/{id}/average

返回平均值

DELETE/list/{id}

删除列表

---

GET/list/{id}/average

的另一个替代方法是

GET/list/{id}

将列表作为结构化数据返回，例如XML，其中包含作为生成属性的平均值

执行

PUT

此操作以指示将生成哈希的新结构，即而不是基于传递的数字。只是一个“随机”散列。然后，每个后续的post都将包含id散列和发送的数字的返回结果散列。然后，当在上显示get时，您可以缓存结果

1. PUT    /api/average/{number} //return id-hash
2. POST   /api/average/{id-hash}/{number} // return average-hash
3. GET    /api/average/{average-hash}
4. DELETE /api/average/{id-hash}

---

然后，您可以缓存平均哈希的get，即使您可能以不同的方式获得结果，或者不同的服务器获得相同的平均值。

您所说的是将请求表示（数字列表）无状态转换为响应表示（单个数字）

让我们对您的资源进行分类：

• 无状态——请求是无状态的，但资源也是无状态的。它应该能够接受您的请求、处理请求并返回响应，而无需维护任何内部状态。下文将作进一步讨论
• 不太可能是可缓存的--我在这里假设您的数字列表从不相同/很少相同
• 幂等元——请求没有副作用。这是因为资源是无状态的

现在让我们检查不同的HTTP方法：

• 获取-获取资源的状态。由于您的资源没有状态，因此不适合您的情况。（幂等，可缓存）
• 删除-删除资源或清除其状态。也不适合你的情况。（不是幂等的，不可缓存）
• PUT-用于设置资源的状态（如果资源不存在，则创建资源）。（幂等，不可缓存）
• POST-用于处理可能修改或不修改资源状态的请求。可能会创建其他资源。（不保证幂等性——取决于资源是有状态的还是无状态的，不可缓存）

正如您在其他答案中所看到的，POST最常用作“创建”的同义词。虽然这是可以的，但POST并不局限于REST中的“创建”。Mark Baker在这里很好地解释了这一点：（第3.1.4节）

虽然POST并没有一个完美的语义映射来解决您的问题，但它是所有HTTP方法中最好的一种。它还带来了一个简单的、无状态的、可伸缩的解决方案，这就是REST

总而言之，你的问题的答案是：

• 方法：邮寄
• 请求：数字列表的表示形式
• 响应：单个数字的表示（列表的平均值）

虽然这看起来像SOAP风格的web服务调用，但事实并非如此。不要让您对SOAP的本能反应影响您对POST方法的使用，并对其施加不必要的限制

---

KISS（保持简单，愚蠢）。

不能只返回哈希或ID，必须返回URI或URI模板加上字段值。唯一可以作为API一部分的URI是入口点，否则您的API就不是REST。

您能提供更多的上下文吗？例如，您使用什么编程语言进行调度？编程语言的选择不一定会影响REST API的设计。这似乎是一个很好的答案，但是如果客户端忘记了{id}，服务应该何时或如何确定何时删除{id}？我个人只会设置一个计时器任务，每天删除一次“旧”列表。除非列表非常庞大或频繁，否则您可能能够存储一年的价值。