这是一个创建于 1772 天前的主题，其中的信息可能已经有所发展或是发生改变。
我公司需要建一个新系统(后端是 thinkphp 6)，对接接口时候，前端说我接口不对，我看了一下接口和参数，发现参数不对。他请求编码方式 application/json，我的是 application/x-www-form-urlencoded 方式，我就说他参数不对，需要跟我们 ERP 系统一样，他说 erp 系统改过，他不会改，也不知道怎么改。扯来扯去，想让我来改。我当然不愿意改，那我代码自测没问题，还要我来改，最后问组长说统一规范，说以后 put 请求编码方式都用 application/json，我服了。六字真言在心中。哎
 |
1
wangcansun 2020-02-23 01:01:28 +08:00
现在整体范围内，不是 json 才不正常吧。。。。。
json 和前端的对象是通用的，所以 json 对前端来说更友好。 而且现在更多地 api 服务商提供的都是 json 格式吧 |
 |
2
chendy 2020-02-23 01:12:45 +08:00  1
不是 put 用 json，是全部 body 除了文件上传都 json
毕竟 urlencoded 不好处理复杂对象和数组，就全部统一好了 |
 |
3
nvkou 2020-02-23 01:17:29 +08:00 via Android
编码方式…以为要说 gbk 和 utf8
php 多半是用 curl 做客户端。post 数组会自动转换头为 form encoded。算是后端不精。 另。put 可以有 body 的吗 |
 |
4
WytheHuang OP @wangcansun 我能理解，问题是前端就一句话不会就让改
|
|
6
wangcansun 2020-02-23 01:24:40 +08:00
@WytheHuang 沟通方式确实有问题，不可能说应为不会而不改。。。。别想太多了。。。。
|
|
7
WytheHuang OP @wangcansun 他说 erp 系统改动，不知道 erp 是如何改，让我后端按 application/json 来。这一点是我不爽的点。
|
 |
8
ss098 2020-02-23 02:03:31 +08:00
根据你的描述如果前后端分离的话，使用 application/json 是很合理的。
|
 |
9
lidashuang 2020-02-23 04:03:17 +08:00
rails 来说, 不管 application/json 还是 application/x-www-form-urlencoded 都没框架抽象来
比如直接用 params[:name] 就行 别用 thinkphp 了 |
 |
10
lihongming 2020-02-23 04:04:20 +08:00 via iPhone
说参数不对没问题啊，form 方式你收到的是一个数组，各“参数”都都给你分好了。而 json 方式整个 body 都是数据，你自己从 json 对象里找数据，总共就一个“参数”
|
|
11
nvkou 2020-02-23 04:19:55 +08:00 via Android
@lidashuang 这个真的要说，对接很多国内公司文档都只说一个 post 根本不提 content type。可现实是 Apache 或 nginx 等很多反代因为安全设置是限制 content type 的。直接 401 比走业务快。
|
 |
12
Reficul 2020-02-23 07:59:47 +08:00 via Android
按规范来，前端请求里 allow 什么后端返回其中格式的内容，保持头和内容一致。
|
 |
13
sujin190 2020-02-23 09:30:16 +08:00
既然如此，为啥不能按 content-type 来解码，前端爱用啥用啥呗，http 都给你定义好了，没必要纠结吧
|
 |
14
Muninn 2020-02-23 09:30:20 +08:00
这个问题竟然是一个后端提出的……
难道不是平时都是前端不理解为啥要用 json 去 put 和 post 么……很多框架默认的都不是 json 要加一行 content type 可能 php 是世界上最好的语言吧 |
 |
15
manami 2020-02-23 09:34:50 +08:00 via Android
我站 application/json
|
 |
16
blless 2020-02-23 09:40:30 +08:00 via Android
我司都是 json，每个系统都是。除非外部系统，听起来你们 ERP 也是第三方系统，主动适配是应该的。
|
 |
17
binux 2020-02-23 09:44:36 +08:00
是你的问题
|
 |
18
sadfQED2 2020-02-23 09:53:59 +08:00
我觉得吧，讲道理，application/json 比较合理
|
 |
19
cloudzhou 2020-02-23 10:37:49 +08:00
application/json 的表现力，比 application/x-www-form-urlencoded 多多了，尤其是层级多的情况下
如果是文本为主，我赞同你组长的统一规范 |
 |
20
sagaxu 2020-02-23 10:43:03 +08:00 via Android
tp 用户果然都一样
|
 |
21
ZSeptember 2020-02-23 10:55:19 +08:00
put 不是用 json+body 吗。
现在主要用的 rest 是这样的。 看看 stripe 的 API 设计，其实 RESTful 的表达能力已经足够了。 |
 |
22
MengiNo 2020-02-23 11:56:17 +08:00 1
看之前习惯和文档情况或者之前项目、公司内部规定了都走 json 就是 json。不然前端随心所欲写个 content-type 然后传个对应的 body 不是给后端徒增麻烦，和什么语言什么框架有什么关系。根本不是 php 还是 thinkphp 能不能解析的问题，反过来说，后端也别返回 json 了，直接 content-type 写个 text/html，body 里搞成 string 就完了。
|
|
23
WytheHuang OP ERP 系统项目是用 application/x-www-form-urlencoded， 新项目并没有一开始说要用 application/json， 而是前端对于 ERP 项目用 application/x-www-form-urlencoded 不知道，但他觉得太复杂了，不会改。于是让我来改，最后居然说统一规范。用那个我都可以，问题是由于他的不会，强行规范这一点是我无法忍受的。
|
 |
24
TristanYang 2020-02-23 12:09:58 +08:00
除了文件上传，application/json 优先，前端怼的对。
|
 |
25
zjie 2020-02-23 12:16:23 +08:00
讲道理，除了文件上传 ，body 里面放 application/json 更好处理，也更加主流。最近几年的系统，应该都是这种格式吧。
|
|
26
MengiNo 2020-02-23 12:22:01 +08:00
@WytheHuang tp 作为一个成熟的框架 tp5 遵循 psr7 之后支持 application/json 应该就就是分分钟的事情。tp6 虽然没有了解过 但是估计最差的情况下就是写一个 middleware 复制一遍就好了。
我猜测你早期的 erp 用的是 jq 所以 $.ajax 默认是 application/x-www-form-urlencoded 格式 现在新项目可能改用 vue 之类的像 axios 包所以默认都是用 json。 换的话他们转一下 data 格式 但是 object.assign 函数不兼容 iOS10 以下的老浏览器 所以就比较麻烦 （我不怎么会前端仅是猜测可能不对） 后端至少在项目范围内肯定要一个统一的格式这个是肯定的，其次 application/json 应该来说是默认的一个比较标准的格式 无论怎么说后端在 restful 的情况下弄成不支持 json 的确是一大失误。 |
|
27
WytheHuang OP @TristanYang #23 你看了全文吗，是他不会，而去统一
|
 |
28
liukanshan 2020-02-23 14:47:14 +08:00 1
不论对错 你同事的态度应该有问题 引起你的不适。
|
 |
29
wangyzj 2020-02-23 14:48:53 +08:00
这可能是历史遗留问题把
但我觉得还是 json 类型比较好 我建议方向还是改成 json 如果一次性都改不现实的话就分批改 或者做个中间层 |
 |
30
iMusic 2020-02-23 15:47:44 +08:00
沟通下统一了改下不就得了，就这也值得抱怨？同事之间关系这么差？
|
 |
31
msg7086 2020-02-23 16:57:15 +08:00
Rails 开发人员表示 JSON 和 urlencoded 和 multipart 对我来说都一样……
|
 |
32
qile1 2020-02-23 23:25:48 +08:00 via Android
datatable 里面读取数据是 steam 模式，要不数据不显示
|
Select Language