给定一个标准的Node.js HTTP库或一个现有的REST客户端库，哪种方法允许这种库通过我自己的协议执行这些HTTP请求是最可行的方法？
换句话说：我的目标是提供一个看起来像HTTP客户端的模块。它接受HTTP请求标头，并返回HTTP响应。与标准的节点库HTTP客户端相比，我应该考虑哪些选项来使现有的REST库适合我的“伪” HTTP客户端模块使用？
更多背景信息
我希望创建一个服务器应用程序（基于Node.js），该应用程序向远程嵌入式设备发出HTTP REST请求。但是，由于存在NAT，应用程序服务器无法直接将客户端TCP连接建立到远程设备。因此，为了避开NAT，我将设计自己的专有协议，其中涉及远程设备启动与应用程序服务器的持久连接。然后，一旦建立了持久连接，Node.js应用程序将能够通过该持久连接向网络设备发出HTTP请求。
因此，我的目标是创建一个Node.js模块，该模块充当来自网络设备的传入套接字连接与发出REST请求的主应用程序之间的“桥梁”层。目的是使应用程序发出REST请求，就像向服务器发出HTTP客户端请求一样，而实际上HTTP请求和响应是在专有协议之上传输的。
我目前正在考虑的一个选项是让我的“桥”模块实现一个模仿接口的接口，http.request(options,[callback])并以某种方式强制REST客户端库使用该接口而不是Node HTTP客户端。至少我必须稍微修改我用来实现此目标的任何REST客户端库。
如上所述，我实际上是在尝试使用中介服务器创建自己的NAT遍历形式。中间服务器将向用户提供前端UI，并向嵌入式网络设备发出后端数据请求。嵌入式设备和应用程序服务器之间的连接将是持久的，并从嵌入式设备启动，以避免常见的NAT麻烦（即配置端口转发的要求）。
尽管我之前提到过，我将使用我自己的协议通过原始套接字连接来实现设备到服务器的连接，但是我现在正在实际尝试的机制是将纯HTTP与长轮询一起使用。嵌入式设备启动与应用程序服务器的HTTP连接，并且当服务器需要发送某些内容时，延迟的响应用于将数据传送回该设备。然后，我将以“隧道”的方式在相反的顶部进行HTTP请求。
因此，简单来说，我的“桥接”层是从两侧向内接受HTTP连接（外部设备连接以及内部Web应用程序REST请求）的层。通过使用长轮询，它将有效地在连接的客户端之间传达请求和响应。
创建中间人而不是替换http层。在节点中创建一个http服务器，该服务器是所有其余请求的目标。然后，它将请求传输到专有协议上，并通过转换回静态来处理响应。
这样，您不必破解其余代码，甚至可以根据需要将其换出另一个库。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句