Web 技术研究所

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

RPC 是否应该带 Header?

  最近想在 RPC 调用时传输一些额外的信息,把这些信息放在内容里又觉得太恶心,于是就感叹还是 HTTP 好,可以通过头字段来传输一些业务数据之外的额外信息。可是用 HTTP 的时候又觉得,参数可以通过各种渠道传输,服务器不知道参数会从哪里传过来才是一件恶心的事情。
  这个问题纠结得我都要炸了。到底是纯净的 RPC 好还是像 HTTP 那样有各种数据传输渠道的好?
  以前写后端业务的时候总是纠结前端的参数会如何传输过来?QueryString?Body?Cookie?Header?于是有时候会无差别地从「请求」参数中获取参数,无视这些参数的来源。当时觉得就觉得,为什么要分那么多数据传输方式?统一成一种多好。
  最近纠结的事情刚好相反,搞 RPC 的时候希望带一些业务数据之外的额外信息,比如对调用链的监控信息等。虽然放在业务中也能实现,但这会让业务上的所有接口定义都要加上这个参数,变得非常恶心。
  现在觉得,传输协议提供元数据传输还是有必要的,就像 HTTP 的 Header 那样。但是传输应该是层对层的,通过传输协议提供的元数据来传输的内容就应该在对应的层上解析。HTTP 其实并没有问题,QueryString、Body 确实是 HTTP 特有的风格,对它们做区分的原因和 HTTP 的设计初衷有关。而 Cookie 本来就属于 Header。也就是说 HTTP 分为「业务参数」、「会话参数 Cookie」、「传输参数 Header」。Cookie 作为会话参数,由服务器端的会话中间件使用;Header 作为传输层参数由服务器端的传输中间件使用。前端程序当然也不仅仅是业务,我们同样可以封装出这三层来做对应的操作。
  以前觉得 HTTP 的参数传输繁琐完全是因为自己没做好分层。比如把一些业务相关的东西放到 Cookie 和 Header 里面就是错误的做法。
网名:
54.211.148.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^