Web 技术研究所

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

为什么纠结参数传递方式?

  HTTP 请求有多种参数传递方式,最常用的就是 URL 参数和请求实体了。后端程序也经常会在 API 文档中规定某个数据通过某种方法传到服务器。但是这真的有必要么?我觉得让后端框架把所有渠道的请求都整合起来一起处理会更方便,不需要纠结参数到底通过什么方式传的。
  就像 PHP 中有 $_GET 和 $_POST 可以很明确地获取来自某个渠道的参数,但我可能更喜欢 $_REQUEST,直接无视渠道来获取。但是这里不是推荐 PHP 使用 $_REQUEST(PHP 的 $_REQUEST 本身设计得并不好),而是在推广这个思想。我觉得后端开发者没必要只要参数来自哪个渠道,任凭前端爱怎么传就怎么传,这样不仅更加灵活,还避免了选错参数传递方式的问题。
  也许有人觉得,如果两个渠道中存在同名参数怎么办?我觉得如果这遇到这样的情况,那只能说明这个 API 设计太烂了。还是拿 PHP 为例,假如 $_GET 和 $_POST 中都传入名为 id 的参数,那么代码里需要同时使用它们时应该选择什么样的变量名?反正我是想不到了。所以即使是不同渠道传递的参数,也应该要有不同的名称。要不然开发时就会使用一些奇奇怪怪的变量名,代码会变得很难读。
  有时候客户端传过来一个鉴权的 Token 服务器端还要考虑是从 Header 还是 Cookie 还是 QueryString 传过来的?那就太麻烦了!其实如果有需要也可以把 Header 中的非标准头和 Cookie 都作为参数,并把它们和其它参数放在一起。   最后值得一提的是 URL 参数能这么玩的也只有 QueryString 而已,放在 URL Path 部分的东西无法随意改变传递方式,就只能靠后端路由系统去解析成参数。
网名:
54.161.8.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^