Question

我有一个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服务，则将创建具有“ parse”含义的函数。这意味着它接受原始数据并返回更新的设备对象（或替代地，仅设备对象中包含已解析状态的部分）。但是我怀疑我是否可以为这种功能找到一个好的REST解决方案。现在，我正在通过PATCH进行此操作，但是我个人不喜欢此解决方案，因此在此不再提供。我相信这类问题应该有很好的解决方案。

问题是：我该如何在REST范式中适应我的“解析”逻辑？

Answer 1

POST到一个/parsed-device-state URL，它将返回一个201 Created，一个Location标头，指向您可以从中获取解析数据的位置，如果您也可以在201中返回解析后的数据（以及与Content-Location头具有相同值的附加Location头）。或者，如果解析时间很长，请使用202 Accepted和相同的Location标头。然后，呼叫者可以轮询提供的位置，直到结果准备就绪。

Answer 2

问题是：我该如何在REST范式中适应我的“解析”逻辑？

您如何将解析逻辑适合网站？

您可能会以书签开始。 GET $BOOKMARK将返回 form 的表示形式。该表单可能包含一个输入控件，例如文本区域元素，该控件将允许使用者输入表示形式，或者可能包含一个输入控件，该控件允许使用者链接到文件中。消费者将提交表单，而代理将根据表单中的信息创建请求。这可能是对指定为表单操作的任何资源的POST（您不太可能在查询字符串中包含任意文件的表示形式）。服务器的响应将提供结果的表示。

如果解析是一个特别缓慢的过程，则响应可能是一种表示形式，包括指向可用于跟踪解析进度的资源的链接。在这种情况下，整个协议看起来很像将工作放在队列中，然后轮询更新。

这是不适合HTTP的问题的正确答案：

REST接口被设计为对于大颗粒超媒体数据传输是高效的，针对Web的常见情况进行了优化，但是导致的接口对于其他形式的体系结构交互不是最佳的。

在某种程度上，您要使用函数进行的操作是转移计算，这可能就是为什么您感觉要从桩钉上修剪掉边角以使其适合孔的原因。

一种更适合HTTP的替代方法是考虑转移行为的表示形式。 API客户端获得一个了解如何将苹果解析为橙色的函数，然后根据其在本地保存的信息运行该代码。考虑一下Java脚本-我们从服务器获取行为的表示形式（可以将其嵌入到客户端需要的服务器具有的表示信息中），然后在本地执行结果。标头中的元数据以任何符合标准的缓存都可以理解的方式描述了表示的生存期。

使“解析”功能为RESTful

2 个答案: