Web 技术研究所

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

REST API 设计之 —— 类型

  这个标题也许会让很多人觉得费解。类型有什么好说的?谁不知道有哪些类型么?如果 API 约定使用 JSON,那么数据类型就是 JSON 所支持的哪几种嘛。我觉得,API 设计中所规定的数据类型不应该依赖于任何语言环境。也许我们的 API 根本就不基于 JSON 呢?
  我觉得 API 类型只能分为两种。一种是列表类型,另一种是非列表类型。请注意这里强调的是 API 类型,而不是 API 传输的数据类型。作为框架的开发者,当我在处理 API 时根本不想知道这个 API 的内容结构是什么样的,因为内容结构只有在业务代码中才会用到。我关心的只是这个 API 响应的到底是一个列表还是一个其它什么东西。
  如果是基于 JSON 的 API 设计,其列表类型则可以通过数组的形式呈现。但并不是所有数组都是列表,比如有这么一个数组 [ { "a": 1 }, { "b": true }, { "d": "x" }, { "g": null } ]   这个数组每一项都是不同格式的对象,所以它只是个纯粹的数组而已,称不上是一个正常的列表类型。
  类型是什么?JSON 的数据类型非常有限,但类型的概念未必是语言提供的基本类型。在 C++ 中类就是类型,想要什么复杂的类型 typedef 出来就行了。当对象内的结构相同时才会将其视为同一类。上面的例子中,数组内各个对象的结构完全不同,所以这个数组不是一个「强类型」数组(此处的强类型数组概念不是 JavaScript 中的那个概念),所以它不是一个真正意义上的列表类型。
  框架区分列表类型和非列表类型的目的是对他们封装一系列框架级的操作。对于非列表类型,框架内就可以提供一套字段选择的功能。比如一个接口调用返回一个对象,这个对象上又好几十个键,然而业务只用到其中一个,那么通过框架内实现的一组语法就可以将对于的键在服务器端过滤掉,这可以很大程度地降低网络传输成本。对于列表类型,我们不仅可以对列表内所有元素都统一做非列表类型的操作,还可以对列表做筛选、排序、截取等一系列操作。
  总之,将 API 分为列表和非列表才是最重要的!至于更细的类型,什么数值、数字、布尔,甚至更细到整型、无符号整型、浮点,这些细分的影响是非常微小,可能分太细会导致使用起来不方便。我的建议是 JSON 的那几个类型就足够了,更细的不容易控制,毕竟 Web 前端程序只能是 JavaScript,这是不可选的。
网名:
34.203.245.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^