本想法的应用场景仅限于“请求-应答”式的数据交换方式下(如HTTP)。 先描述一个普通的web应用的运作( 不要在意细节 ;b )

  1. Client 向Server发出请求;
  2. Server 收到请求处理之,然后发出应答;
  3. Client 收到应答,然后解读应答;

普通web应用的运作过程就是不断地重复以上步骤。这有点像我们人与人之间对话的过程,我将之拟人化也毫不违和:

  1. Client君向Server君提问;
  2. Server君回答了Client君;
  3. Client君收到答案并根据答案做出反应;

奈何程序员能力有限,还无法让Client与Server如人一样智能地对话(扯AI我就暴露了,赶紧扯回来)。他们只能为Client和Server立一个约定,这个约定定义了Client与Server之间传递的各项数据的含义。Server按约定来提供数据,Client按约定来解读数据。至于数据的格式,那得另起话题了。

(题外话:二进制如 Msgpack,Protocol buffers等等,可读文本如 JSON,XML,甚至是脚本语言源码(如JavaScript))

如此,项目一开始程序员们分分钟就约定好了数据的含义:“接口A返回数据dataA,接口B返回数据dataB……”。Client和Server轻松快乐地进行着“你问我答”,程序员们便安心回家睡觉觉了,皆大欢喜……意淫结束,我们来看下实际情况中的问题:

  1. 数据含义的约定无法复用或极难复用。想象一下,如果多个接口返回的数据中都包含了dataX,如何避免重复地约定dataX各项数据的含义?
  2. 数据含义的约定与提供数据的Server接口绑死了,于是Server接口A必须返回约定好的dataA,不能是dataB,否则霹雳啪啪轰隆咔咔出事故扣工资卷铺盖。当然,你也可以约定好接口A会返回的dataA或dataB,但这又回到问题"1"了。

假设某个Server接口专门提供“现在几点钟?”这种问题的答案,返回的数据已经约定好是个时间描述,如“2013-07-02 01:33:26”,但是某些极端情况也需要考虑,譬如“我没带表,你可以问其他Server。”,或者离奇点的情况:“我已经挂球了,现在你听到的是十年前我临死前的录音。”。

对掌握了自然语言的人类来说,表达和处理以上例子中的信息实在小case.但对于程序,则需要对每种情况约定好相应的数据含义。至此,程序员们应该会感觉到Client与Server之间“交流”有点困难了,如果这时候还不反思这种毫无设计的做法的话,估计是打算玩命领加班费了。

好的 现在加一丁点设计,我给每个数据集合加入唯一标识(非绝对唯一,仅让不同数据集合的标识唯一即可),而数据含义则围绕着唯一标识来进行约定,Client根据这个唯一标识来处理对应的数据集合。如此,每个数据集合都通过唯一标识来区分,只要Server接口返回了带有这个唯一标识的数据集合,Client都能根据唯一标识来“理解”,对于表示意外情况的数据含义也只需要约定一次即可。

  1. 举个解决坑1的例子,我们将{气温、天气、风力、地点、标识}这个数据集合中的标识定义为“天气预报”,那么对于任何Sever接口返回的带有“天气信息”标识的数据集合,Client都按“天气信息”的约定来处理这个数据集合,丝毫不用理会这个“天气信息”是来自哪个Server接口,而这个“天气信息”的数据含义只需约定一次。
  2. 举个解决坑2的例子,假设Client向Server请求“天气信息”,而这时候Server可能会碰到多种情况:
  • 生成“天气信息”的操作未完成,可以返回标识为“稍后再试”的数据。
  • Client的Session信息过期了,可以返回标识为“重新登录”的数据。
  • Server停服中,可以返回标识为“停服”的数据(包含一条文字公告更好)。
未完待续……
欲知后事如何,请再听下个月分解。