HATEOAS作为领域特定协议描述的引擎

要解释清楚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