PlugFest
Sapporo(2015-10)
This first WoT PlugFest elaborated, based on a JSON-LD thing description, server and client role of "thing". Protocols such as CoAP, HTTP and WebSocket were combined with JSON and EXI encodings.
Goals
Interoperable（互通） applications by means of a thing description only
Outcome
Thing description registry and discovery is needed
Nice(2016-01)
Goals
Based on the previous PlugFest in Sapporo four advances will be proposed.
Security: using new security mechanisms that emerged for protecting new styles of Web applications (Web/REST APIs, browser-based/mobile apps) in the things space
APIs: generic APIs to program behavior for a thing or interact with a thing
Thing registries: practical registration and discovery of a thing
HATEOAS: application of REST-based hypermedia controls in the thing world
Outcome
Registry & Discovery
As a finding of the Sapporo plugfest we concluded that it would be very helpful to provide a mean of registering things. Moreover, finding an appropriate counterpart（配对） is even more important.
Hence we plan to work on such a registration authority and define ways to discover matching things.
Scripting API
In the area of data exchange between things we so far agreed on using certain protocols (CoAP, HTTP, Websocket) and encodings (JSON, EXI). The proposal for this plugfest is to go beyond that level and work on an actual API. On this basis, we can elaborate（详细描述） exposing and accessing things by such an abstraction layer.
The idea is to agree on an abstract interface definition which than can be mapped to various programming languages. For this purpose, we plan to use WebIDL（Interface Definition Language，接口定义语言） for defining the abstract WoT API (maybe along with the JavaScript mapping) to enable API-based communication.
HATEOAS
This aspect offers the possibility to bridge W3C efforts with IRTF（Internet Research Task Force，互联网研究专门工作组） RG and the plugREST initiative.
REST架构
REST 是 Representational state transfer 的缩写，翻译过来的意思是表达性状态转换。REST 是一种架构风格，它包含了一个分布式超文本系统中对于组件、连接器和数据的约束。REST 是作为互联网自身架构的抽象而出现的，其关键在于所定义的架构上的各种约束。只有满足这些约束，才能称之为符合 REST 架构风格。REST 的约束包括：
客户端-服务器结构。通过一个统一的接口来分开客户端和服务器，使得两者可以独立开发和演化。客户端的实现可以简化，而服务器可以更容易的满足可伸缩性的要求。
无状态。在不同的客户端请求之间，服务器并不保存客户端相关的上下文状态信息。任何客户端发出的每个请求都包含了服务器处理该请求所需的全部信息。
可缓存。客户端可以缓存服务器返回的响应结果。服务器可以定义响应结果的缓存设置。
分层的系统。在分层的系统中，可能有中间服务器来处理安全策略和缓存等相关问题，以提高系统的可伸缩性。客户端并不需要了解中间的这些层次的细节。
按需代码（可选）。服务器可以通过传输可执行代码的方式来扩展或自定义客户端的行为。这是一个可选的约束。
统一接口。该约束是 REST 服务的基础，是客户端和服务器之间的桥梁。该约束又包含下面 4 个子约束。
【资源标识符】。每个资源都有各自的标识符。客户端在请求时需要指定该标识符。在 REST 服务中，该标识符通常是 URI。客户端所获取的是资源的表达（representation），通常使用 XML 或 JSON 格式。
【通过资源的表达来操纵资源】。客户端根据所得到的资源的表达中包含的信息来了解如何操纵资源，比如对资源进行修改或删除。
【自描述的消息】。每条消息都包含足够的信息来描述如何处理该消息。
【超媒体作为应用状态的引擎（HATEOAS）】。客户端通过服务器提供的超媒体内容中动态提供的动作来进行状态转换。
在了解 REST 的这些约束之后，就可以对“表达性状态转换”的含义有更加清晰的了解。“表达性”的含义是指对于资源的操纵都是通过服务器提供的资源的表达来进行的。客户端在根据资源的标识符获取到资源的表达之后，从资源的表达中可以发现其可以使用的动作。使用这些动作会发出新的请求，从而触发状态转换。
HATEOAS约束
HATEOAS（Hypermedia as the engine of application state）是 REST 架构风格中最复杂的约束，也是构建成熟 REST 服务的核心。它的重要性在于打破了客户端和服务器之间严格的契约，使得客户端可以更加智能和自适应，而 REST 服务本身的演化和更新也变得更加容易。
在介绍 HATEOAS 之前，先介绍一下 Richardson 提出的 REST 成熟度模型。该模型把 REST 服务按照成熟度划分成 4 个层次：
第一个层次（Level 0）SOAP、XML-RPM都属于这一级别，仅是来回传送"Plain Old XML"(POX)。即使没有显式调用RPC接口（SOAP、XML-RPM），通常会调用服务器端的一个处理过程。一个接口会有一个端点，文档的内容会被解析用还判断所要调用的处理过程及其参数。这种做法相当于把 HTTP 这个应用层协议降级为传输层协议用。HTTP 头和有效载荷是完全隔离的，HTTP 头只用于保证传输，不涉及业务逻辑；有效载荷包含全部业务逻辑，因此 API 可以无视 HTTP 头中的任何信息。
第二个层次（Level 1）的 Web 服务引入了资源的概念。每个资源有对应的标识符和表达。
这些资源仍是被"GETful"接口操作而不是HTTP动词，但服务基本上提供和操作资源。例如：
GET http://example.com/app/createUser
GET http://example.com/app/getUser?id=123
GET http://example.com/app/changeUser?id=123&field=value
GET http://example.com/app/deleteUser?id=123
第三个层次（Level 2）的 Web 服务根据语义使用HTTP动词，使用不同的 HTTP 方法来进行不同的操作，并且使用 HTTP 状态码来表示不同的结果。
GET用于查询资源；
HEAD用于查询资源是否存在；
POST创建新资源；
PUT更新已存在的资源；
PATCH部分更新已存在的资源；
DELETE删除已存在的资源。
第四个层次（Level 3）的 Web 服务使用 HATEOAS。在资源的表达中包含了链接信息。客户端可以根据链接来发现可以执行的动作。
对于不使用 HATEOAS 的 REST 服务，客户端和服务器的实现之间是紧密耦合的。客户端需要根据服务器提供的相关文档来了解所暴露的资源和对应的操作。当服务器发生了变化时，如修改了资源的 URI，客户端也需要进行相应的修改。而使用 HATEOAS 的 REST 服务中，客户端可以通过服务器提供的资源的表达来智能地发现可以执行的操作。当服务器发生了变化时，客户端并不需要做出修改，因为资源的 URI 和其他信息都是动态发现的。
Montreal(2016-04)
Goals
Compared to previous PlugFests we do not plan to introduce new technologies nor additional parts. Instead we focus on a broader support of the same features by different implementations（对同一功能支持不同实现）.
Moreover, we especially encourage real-world scenarios in the following two areas:
Thing-to-thing communication and interactions
Scripting API
Former PlugFest participants are well aware of the available thing acting and sensing capabilities（感知能力）. That said, we would like to stimulate new scenarios based on what we have seen so far (e.g., discover thing properties and combine（组合） them with other thing actions and/or events). Feel free to come up with rather sophisticated real-world use-cases. Please also make use of the discovery to improve PlugFest preperation and enable onsite combination of things.
