我有一个 RESTful 服务，可以让我们说设备。它提供了非常常见的功能：
GET /devices
GET /devices/:id
POST /devices
PUT /devices/:id
DELETE /devices/:id
设备对象可能定义如下：
{
id: 123,
name: "Smoke detector",
firmware: "21.0.103",
battery: "ok",
last_maintenance: "2017-07-07",
last_alarm: "2014-02-01 12:11:10",
// ...
}
有一个应用程序可以通过某些特定于设备的阅读器读取设备状态。应用程序本身不知道如何解释读取的数据，但它可能会要求服务器来做。在我们的例子中，我们假设数据包含以下内容：电池状态、固件版本、上次警报。
如果我要实现常规的 RPC 服务，我会创建具有“解析”含义的函数。这意味着它接受原始数据并返回更新的设备对象（或者，仅包含解析状态的设备对象部分）。但我怀疑我能否为此类功能找到一个好的 REST 解决方案。现在我是通过PATCH来做的，但我个人不喜欢这个解决方案，因此我不会在这里提供它。我相信这类问题应该有很好的解决方案。
所以问题是：我应该如何在 REST 范式中适应我的“解析”逻辑？
POST将它发送到一个/parsed-device-stateURL，它将返回一个201 Created，一个Location指向您可以从中获取解析数据的位置的标头，并且如果您愿意，还可以返回 201 中的解析数据（以及具有Content-Location相同值的附加标头）的Location标头）。或者如果解析需要很长时间，使用202 Accepted, 和相同的Location标头。然后调用者可以轮询提供的位置，直到结果准备好。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句