关于 HTTP 请求， POST 请求为什么有的接口还在 url 里传参数呢？

• 資深大佬 : myCupOfTea

  post 用 path var 倒是可以理解，还用 params 我不太能理解为啥要这么干

• 資深大佬 : halk

  因为 HTTP 协议并没有禁止

• 資深大佬 : domybestFujian

  因为偷懒

• 資深大佬 : shiny

  比如钉钉的设计，不管是 GET 还是 POST，AccessToken 都放 query string 中，风格保持统一。

• 資深大佬 : bitholic

  Nginx 等比较好把 query string 打印出来

• 資深大佬 : GM

  有时候这样比较方便。
  比如 /api/wtf?v=a 和 /api/wtf?v=b

  代码里可以根据 v 的值的不同，用不同版本的 handler 来处理 body 。

• 資深大佬 : zhuweiyou

  qs 和 body 又不冲突

• 資深大佬 : GM

  补充上面：
  然后 handler 里就可以保持纯净，不需要做跟业务无关的判断。

• 資深大佬 : jinzhongyuan

  @halk 应该是实现的库没有禁止哈

• 資深大佬 : misaka19000

  为什么晚上吃了肉还要吃蔬菜呢

• 資深大佬 : marquina

  @myCupOfTea path var 不就是 params 吗

• 資深大佬 : momocraft

  什么叫多此一举，你 post 过除了 json 和 form 的东西吗

  > 9

  以 RFC 为准，http (包括 uri) 就是没有禁止，请不要自己加戏

• 資深大佬 : myCupOfTea

  @marquina 表达不清楚,pathParams 理解,queryParams 不理解

• 資深大佬 : xiangyuecn

  分析一下 HTTP 请求格式就知道了

  部分参数放 url 里，你就不用读取请求 input stream （这玩意往往是只能读一次），就能拿到某些必要的参数，用处很大的，不然 form 、file 、raw stream 等操作是要读取并解析 input stream 后才能拿到参数的

• 資深大佬 : myCupOfTea

  @misaka19000 主要 java spring 里面 一个是 @PathVariable,一个是 @RequestParam,说习惯了

• 資深大佬 : woodensail

  做鉴权很有用。服务端可以在 option 请求过来的时候就把请求干掉，不需要接收 post 的请求体了。降低鉴权服务器的压力。

• 資深大佬 : ditel

  感觉上传文件又需要签名验证的时候

• 資深大佬 : lxz6597863

  POST /api/user?username=abc

  { “age”:1 }

  update user set age=1 where username=abc

• 資深大佬 : ai277014717

  @lxz6597863 应该用 put

• 資深大佬 : sadfQED2

  只要你高兴，get 请求还能在 body 体里面传参呢

• 資深大佬 : wangyzj

  一种习惯吧
  我习惯 body 里面只提交数据
  不包括已有参数

• 資深大佬 : Jackeriss

  想怎么传就怎么传，你甚至可以把参数写 header 里

• 資深大佬 : Vegetable

  @sadfQED2 #20 NO,这个不行。https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/GET
  规范中 GET 方法是没有 BODY 的，如果你传了是有可能被某些实现丢弃的，属于规范禁止的行为。

• 資深大佬 : kidtest

  nginx hash 可以用到

• 資深大佬 : mmdsun

  因为 body 里面大多是实体之类的映射的。

  像 accesstoken 统一要传的，不可能往实体里面扩展吧。

  这种要么放 URL，要么放 head 了。

• 資深大佬 : sadfQED2

  @Vegetable 浏览器会丢掉，但是如果你只是实现 rpc 调用的话，也能带 body 体，比如 es 的 api 接口就支持 get 请求带 body 体

• 資深大佬 : ClericPy

  1. 设计
  2. 日志分析
  3. 历史遗留

• 資深大佬 : liut2016

  @GM 那可以把版本信息放在 path 里啊

• 資深大佬 : rioshikelong121

  为什么不行呢？有的参数我觉得完全可以放在 querystring 里面。

• 資深大佬 : EminemW

  我把 token 放在 queryString

• 資深大佬 : yukiloh

  我刚用 axios 的时候控制不好,经常就是想传个 json,结果传到 path 上

• 資深大佬 : jerry

  比如全局参数

• 主 資深大佬 : JieS

  @momocraft 不懂就问，激动个什么寂寞？

• 資深大佬 : DOLLOR

  有些中转代理工具处理 url 比 body 方便一些。
  当然，更多的是保持 get 和 post 风格统一，action 之类的参数就直接写在 url search 里了。

• 資深大佬 : otakustay

  你看嘛，一个 HTTP 请求的 URL 放在第一行的
  然后 body 可能是很大的，甚至可能是一个文件，所以 body 有可能是流式处理的
  这也就代表着，如果你需要将一个请求分配到一个具体的函数上去的话，等 body 全部解析完是很慢的也很没必要的
  举个例子，body 是一个文件流的话，只要我分配到了“把文件存起来”这个函数上，这个函数就可以把 body 流对接到 file 流。但如果我没办法分配到函数上，我就要等 body 流读完，把这个流放在内存里（假设内存没爆掉），然后解析 body 分析函数，把整个内存里的流给它，它再存到文件里，这效率多低啊
  所以一些参数放在 URL 是非常合理的，特别是用来鉴权的、判断路由的等等
  当然我可以不用 URL 而用 HTTP 头，但 HTTP 头的危险性在于你不知道中间有哪个 SB 一样的代理自说自画给你改了或者弄丢了……

• 資深大佬 : jiangzm

  这有啥不能理解的，POST 请求中 url 有 query params 一般和接口结构相关，body 里面一般放业务相关的参数。 这好理解了没。
  @JieS @myCupOfTea

• 資深大佬 : Vegetable

  @sadfQED2 #26 没错呀，还有些骚的不行的也能自定义 HTTP 方法，规范毕竟只是一种规范，不推荐这么用大家还是别太奔放的好，如果两边都可控的话怎么玩都行

• 資深大佬 : also24

  今天还在和朋友说，GET 请求也是可以传 body 的啊，RFC 里面并没有禁止这么做 hhh

• 資深大佬 : myCupOfTea

  @also24 但实际上那天你的小伙伴升级成 fetch 来请求,就全部报错了

• 資深大佬 : wangyanrui

  方便且团队中大多数人认可，就可行！

• 資深大佬 : weixiangzhe

  querystring 有长度限制啊， 放 body 里好

• 資深大佬 : GM

  @liut2016
  放 path 上跟放 querystring 没有本质区别，都是把一些参数单独放外面不放 body 里，而且有些框架不支持 path 参数。

• 資深大佬 : GM

  @ai277014717 put，语义是用提交的数据替换目标对象，你这么做的话 username 就没了