Question

系统与子系统之间面临的第一个问题，是系统的整体部署。系统的部署方案几乎决定或限制了大多数有关系统的决策，其中首当其冲的是数据的结构化与预结构化问题。

数据在哪里？数据的型式是什么？数据的量级、频度与粒度如何？这是系统整体部署中避无可避的三个关键问题。我们先讨论 B/S 架构下的数据，通常它们的大多数数据项表现为微数据，其数据粒度小、频度高、可靠性差。

频度高意味着单次处理数据的 CPU 占用要尽可能小，这是维持大的系统处理能力的诀窍。但如果一笔数据的结构不确定，发现数据有效性以及决策计算路径的代价就将变得极其巨大。举例来说，Java 的 Web 应用框架大多提供“将 HTTP Request 转换为一个数据对象”的能力，其优势是在应用层中不需要关心数据来源与有效性。这一方面可以让应用层用类同的方式处理请求，另一方面也可以屏蔽一些框架逻辑，例如通过注解（annotation）来做数据验证。而且在第三个方面，这还可以将服务端与请求端无缝隔离，例如一个应用处理逻辑并不关心请求是来自于 Web 客户端，还是来自于 Open API 接口。

但是“将 HTTP Request 转换为一个数据对象”的代价极其巨大，其本质上是在服务端、在应用服务器的框架层上进行数据的预结构化。如果我们理解这一点，那么我们在 Web 客户端对数据格式进行预处理，并与服务器端将这一规格协商作为协议，其效果将是十分显著的。例如大多数 B/S 应用会面临登录验证的问题，它们需要处理大抵三类需求：

• 如果用户未登录，则一些客户端请求无效；
• 如果用户未登录，则一些客户端请求被保持，并在再次登录后提供服务；
• 如果用户已登录，则可以为客户端请求提供正常服务。

“登录与否”有许多种特定的验证方法，例如是否存在用户名（UserName），是否存在用户会话（SessionId），是否存在验证数据（CertData）等。但我们这里先关注“验证数据的获取”，这在一个 HTTP Request 中有几种来源 1 ：Cookie、Get Fields、Post URL 和 Post Data。其中 Get Fields 与 Post URL 是同类型的东西，因为“Method 为 Get 的表单”中的字段最终会作为 URL 请求中的字段信息提交到服务端，URL 中包括 Path、Action 和 Fields 等。

那么请问，验证信息（以 SessionId 为例）应该在哪儿呢？