要解释清楚 HATEOAS，可是出了名的难缠，为了更为容易的解释它，Nick Gall探讨了 将它作为领域特定协议描述来进行表达这一观点。根据他的说法，HATEOAS 从传统上被描述为：
…着重强调 HATEOAS 要求每个服务器响应都必须不仅包含被请求的数据 - 还必须包含控制信息 (以特殊标记的 URL 形式) 来描述下一个被允许的与服务器交互的集合。正是这一附加的信息 (最小的情况下仅仅是对于更多数据的链接) 将普通的媒体变为了超媒体。
Nick 解释了他是如何以标识–Identifiers (Uri)，格式 --Formats (HTML)，和协议–Protocols (HTTP) 这种 (IF and P) 的方式来看待 Web 接口 (以及相应的 RESTful 接口) 的。根据他的说法，尽管使用 HATEOAS 的 RESTful 应用可以被看作这三个部件 (IF and P) 的总和，但在理解它的时候将超媒体作为一个领域特定协议描述来思考可能更为合适。他指出了 Jim Webber 的“ Rest 巴克”案例 / 演示，在其中叙述了用超媒体来做协议描述。
乍一看这可能很不直观，因为我之前说在万维网里 HTTP 是协议而 HTML 是格式。但是 URL，HTML，HTTP 只是描述领域特定标识，格式，和协议的一般性描述语言。因此，可以把特定的 HTML 页面组织成的 web 想像成一个领域特定协议。
将“超媒体描述协议”这一观念与 WS-BPEL 1.1 规范或 WADL 进行比较是不可避免的。他表示：
其基本的差别在于 WS-BPEL 是基于一次性地以带外的方式 (out of band) 预先将整个静态协议和盘托出的概念。而 HATEOAS 是基于逐步进展的描述这一观念，我认为一个更好的术语应当是即时协议描述 (Just In Time)。[…] 我可以说“每个服务器渐进的响应自描述了当前的协议。”
即时协议描述相对于预先描述有利有弊，表现在工具支持以及这些接口的可发现性上面。“超媒体描述协议”是否是考虑HATEOAS 观念的新思路呢，并且它是否更易于理解呢？
查看英文原文： HATEOAS as an engine for domain specific protocol-description
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论