Web 技术研究所

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

REST API 设计之 —— 实体类型

  在 HTTP 头中,无论是请求头还是响应头,Content-Type 指的都是请求实体的类型。后端响应类型很多,只要浏览器支持就能用,细扯也没意思。而前端请求的类型就非常有限了,手指头都数得过来。所以我觉得一套优秀的 Web API 应该把规范的类型全部支持上。

application/x-www-form-urlencode

  这是旧时代的标准表单传输格式,其数据使用 urlencode 编码,可以有简单的结构。它是类型不敏感的,所有的数据都以字符串的形式定义,所以偶尔也会成为一个坑。我是不太喜欢这个格式的,但它目前依然是使用最广的请求格式,所以无法完全废除它。后端的程序也应该支持这个数据格式,毕竟目前它依然是主流。

application/json

  JSON 虽然由于不适合人类阅读而经常被黑,但它作为传输格式还是很不错的。而且 JSON 是支持类型的,虽然不是支持得很好,凑合着还能用。现代 Web 中也有规范支持在表单上使用 JSON 格式。所以我总是会尽可能地使用这种格式。

multipart/form-data

  但是 JSON 并不是万能的,比如文件传输的需求它就没法完美支持。虽然可以使用 BASE64 之类的方式来实现,但各种方法都有自己的问题,比如 BASE64 会让数据量增大 33%。所以还是原生的 multipart/form-data 格式才最适合这种场景。

呵呵呵

  并不是所有时候都会设置请求头的 Content-Type,比如在 CORS 的情况下前端设置 Content-Type 是需要后端授权的。于是请求就会多出一个 OPTIONS 方法。所以 API 设计时也应该给 Content-Tyep 一个缺省值,客户端可以在设置 Content-Type 的成本太高时选择不设置。
  我个人比较推荐 application/json 这种方式作为缺省。因为它是目前 Web 中最实用的实体类型。虽然可能目前普及率不如 x-www-form-urlencode,但我想 json 应该能逐步取代它。至于 form-data,虽然我没试过,不过感觉 form-data 一般只是上传二进制时才用的,把它置为默认太逗比了。

网名:
34.203.245.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^