Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

「HTTP 不是传输协议也不是 RPC」

  这个标题其实是引用自一篇 15 年前的论文(看来我的思想落后了别人十几年)。我一直把 HTTP 当做传输层协议来用,但这不是因为我不知道 transfer 和 transport 的区别,而是在 Web 这个体系中,能直接使用的最底层通信协议也只有 HTTP 了。
  在业务中确实有大量程序并不是面向资源而是面向事务的,有时候我们不得不把 HTTP 降级为传输层协议来用以满足自己的业务需求。比如「提交订单」这个事务,它可能会操作好多张表,甚至还会调用短信和邮件通知的接口。而 HTTP 方法中只有增、删、改、查,并没有「下单」这个动作。而且「下单」(这是一个非幂等且不可撤销的事务)这个动作不满足增、删、改、查,的任何一个。也就是说,应用层的 HTTP 本身无法描述这个动作,所以我们将其降级为传输层协议,并这个传输层协议上建立一个 PRC 来处理「下单」这个事务。
  所以很明显 HTTP 不是 RPC。那么既然我们将 HTTP 当做传输层协议来用,为什么还说 HTTP 也不是传输协议呢?其实原作中说这个问题只是在扯 transfer 和 transport 的区别。严格意义上来说,HTTP 应该是应用层协议,看它的那些方法设计,很容易就能总结出 HTTP 的本意是用来「操作资源」。我们将其用于传输只是碍于 Web 这个坑而已。要是 TCPSocket API 普及的话,估计就不会再有人拿 HTTP 当传输层协议用了。所以目前的现状可以总结为:HTTP 不是传输协议,只是在 Web 的 TCPSocket API 没有提供之前,只能勉强作为传输层协议来使用
  也许有人会奇怪我今天为什么突然去翻阅那么古老的文献。这是因为踩到坑了。HTTP 无法满足当前业务的 API 设计需求,我正在寻找替代方案。但 RPC 在 Web 上确实还是个窟窿,而将 HTTP 降级为传输层来实现 RPC 我又觉得太脏,于是陷入纠结中。。。
网名:
50.16.97.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^