对于 restfulAPI，一般如何选择交换数据的格式呢？

[temberature]

主要想请教类似 a=1&b=2 和｛ a ： 1 ， b ： 2 ｝这两种的区别

[gamexg]

@temberature 你需要保证前后端的排序、编码等是一致的。记得有一篇 API 文档提到过，个别语言的排序和 API 服务器不一致，需要特殊处理。


@hantsy 即使上了 https ，我也会利用类似签名的方式而不会直接传递 API 密钥做身份认证的。例如目前对于设备的认证就是设备注册时分配一个 id 及密钥，每个请求都会被 hash 签名。密钥只会在设备注册时传递一次，之后不会传递，这个风险还是可以接受的。由于密钥不像密码，更换麻烦，后期即使加上 https ，也不会直接传递密钥。

[railgun]

json 适合用来描述复杂的数据格式
如果只是简单的数据，用哪个都无所谓
还是要从实际出发，比如有的接口是要传文件的，用 json 就不合适了

[FrankFang128]

@temberature 支持两种方式的话，就没有问题了呀。 调用方怎么都不会错，怎么叫推给他们。

[FrankFang128]

楼上说什么 JSON 是事实标准的说法有点问题，
application/x-www-form-urlencoded; 也是标准啊。

按 REST 来说，根据 Content-Type 的值为 application/x-www-form-urlencoded 还是 application/json 做下判断就好了。

[temberature]

@FrankFang128 我的意思不是把麻烦推给他们，是把分析两种方式的利弊推给了他们；在接口方，我倾向在理想情况把一种实现好，毕竟现实中资源和精力是有限的；同意都是标准的说法，但是事实标准是可能存在的。

[jokcy]

@morethansean 你可以用 payload 的方式传数据

[temberature]

@pandada8 有时候确实会遇到自己难以决定或者双方难以一致的问题，这时候我的态度就先实现一种（直觉有时候也管用），在使用经验增长之后，答案自然就有了。 ps ：突然想到“约定大于配置”。

[temberature]

@railgun 文件确实特殊；一个项目中应该都有复杂点的数据，统一的约定还是挺重要的吧

[temberature]

@gamexg hash 时 json 字符串中的顺序也需要注意吧

[temberature]

@jokcy 一直没太明白设计这个的目的

[gamexg]

@temberature 客户端是对序列化后的字符串签名，服务端是先验证签名后反序列化，所以不涉及 key 顺序的问题。

[temberature]

@gamexg 也见过接口的字符串签名算法，其实也可以按 json 这种，不明白为什么要排序:)

[FrankFang128]

我觉得没必要 2 选 1 的，两种同时存在是 OK 的，也是更为常见的。

[yield9tk]

两种可以同属存在。不同的压缩方式，在 accept 中设置即可

[railgun]

@temberature 那就 json 吧，适配性好一点，扩展也方便

[hantsy]

@gamexg 一些 oAuth2 provider 提供了 JWT 支持, 连接的时候使用， Spring 内置了支持（只需要设置）。其他情况真的没看到签名的使用。国内 X 宝 X 度通篇的 Sign ，除了让 API 看起来像屎一样，如果它的加密方法和顺序被预先知道了，我不觉得是安全的。

如果你想做所有请求还要加密， X509 应该可以了吧。我想只有银行级的安全才会有这种要求。

[Geoion]

两个尖括号的流量也省。。。。。

[temberature]

@Geoion 对于用户量亿级的服务，还是有大差别的吧

[jokcy]

@temberature content-type 不一样

[hantsy]

@temberature 针对 Mobile 原生程序（比如 Android ， IOS ）的某些场合可以绕开 HTTP ，特别图片等数据量大的东西，使用更底层的协议通讯，效率更高。其它文本类的，全部用 JSON ，所有平台都通用。

其实， REST API 的设计，只要参考 Github API ， 或者 Heroku 的 API 就好了。设计好的 API ，从根到底下资源是一个树型结构，如 / 是根， /posts 是 Post 资源集合， /posts/2 是 ID 为 2 的单个资源，/posts/2/comments ，是指 ID 为 2 的 Post 下面的所有 Comments 。如果使用 HAL ， 从根开始添加一些必要的 metadata 信息, 下面的所有的资源都应该是可以 Discovery 的，使用 HAL Browser 这样工具是可以可视化整个 API 结构，而不需要借助文档说明。