用于 haskell 中 ECG/EEG 传感器数据的 RESTful 接口(interface)

Question

我正在从事一个项目，我想在其中显示由可移植设备(例如，通过 Wifi 或蓝牙进行无线数据传输的微 Controller )测量的生物传感器 EEG/ECG 数据。为此，我需要与可移植设备/微 Controller 接口(interface)，为此许多或部分设备似乎使用 RESTful interfaces ，但也可能提供 socket 。

带 wifi 的微 Controller 的一个例子是 "spark.io" ，它基于 cortex m3 和 CC3000 无线 Controller ，用于板载 WiFi 访问。要传输的数据每秒大约有 500 到 1000 个浮点值，这些数据应该以尽可能少的延迟到达 REST 客户端。可能像套接字这样的非 REST 方法更适合，但我仍然想测试一种基于 RESTFul 接口(interface)的方法(对此的一个小争论是通过 RESFul 接口(interface)传输数据似乎很常见并且具有良好的库支持)。

问:问题是，通过 REST 接口(interface)与之交互的高性能(在近实时意义上)实现的最佳方法是什么？

我确信这个问题以前已经解决了，但我无法通过谷歌学者或技术/科学博客文章快速找到解释这个问题的论文。我找到的唯一链接是 "rest hooks" ，但我不确定这是否是一个好方法。在 SE 上搜索并没有揭示过去的问题。

旁注:我的方法是首先在 haskell 中实现接口(interface)，以测试 RESFull 接口(interface)的设计和性能。稍后应该使用 Java/Android/spark.io/一些其他微 Controller 移植或实现工作方法。

(请注意这个问题完全是关于体系结构的，而不是关于 haskell 库或任何东西的。如果使用 REST 是最愚蠢的事情，如果有争议，我会接受它作为答案。此外，问题是是否一般来说，微 Controller 网络接口(interface)，特别是它们的 API，比如 "spark.io"，如果它们是通过 REST 实现的，通常是一个愚蠢的想法。是这样吗？如果不是，“近实时”的定义是什么证明了这一点REST 接口(interface)不是一个好主意，因此其他通信方式更好。比如:每分钟读取一个传感器？或者，每秒读取一个，1/10 秒，1/100 秒，1/1000 秒？)

Answer 1

好吧，让我们来看看这个。

REST 不一定是个坏主意，但它有很多您可能不需要的功能。例如，REST 动词不仅用于检索，还用于更新、删除和创建资源。如果这些功能很重要(例如，您需要将某些控制数据发送到 EEG Controller )，那么 REST 会很好。如果您只想快速访问数据流，请考虑使用原始 TCP。

类似地，REST 会将消息打包成“请求”及其“响应”，它们带有一堆“ header ”，指示请求是否可以满足、是否被压缩等。这些可能是很棒的功能，但可能膨胀。您可能希望在每个请求上发出足够的数据，以便 ~1kB 的 header 只是其中的一小部分。但是给定 8 字节 float (doubles)，这需要传输 500-1000 个数据点，您说过这大约需要一秒钟。这就是我们的宿命——总是有 1 秒的延迟吗？

REST 将允许您通过声明 Transfer-Encoding: chunked 来避免一些膨胀，以便客户端可以在单个 block 可用时对其进行操作。因此，我认为这是一个需要做出的架构决策。

我肯定会尽快让 Keep-Alive 工作，这将是我在服务器上寻找要使用的库时的主要功能。 Keep-Alive 是 HTTP 的标准扩展，可避免为每个 HTTP 请求拆除和重建 TCP 堆栈。如果您不这样做，那么您每次发送请求时都会进行一些繁重的协议(protocol)协商。

您必须做出的一个关键决定是您是否要执行 HTTP pipelining或不。您可以将 HTTP 流水线操作与长期请求(您不希望立即响应的请求)结合起来，以实质上“在数据可用时发送数据”(即首先发送 header ，让服务器在数据可用时推出数据并准备好)。这是分块传输的替代方法。

如果您能解决这些问题，那么 HTTP 通常用于每秒发送兆字节，因此您的用例非常适合 REST 的功能。就 Haskell 的 REST/HTTP 库而言，如果您必须自己以某种方式对 Controller 进行编程，主要的选择是 wai、yesod、snap , 和休息。如果您只需要一个 HTTP 客户端，也有一些。