超媒体

开篇词 该指南将引导你使用 Spring 创建 “Hello, World” 超媒体驱动的 REST Web 服务。 超媒体 是 REST 的重要体现。它使我们可以构建将客户端和服务器在很大程度上分离并使其独立发展的服务。为 REST 资源返回的展示形式不仅包含数据，而且还包含与相关资源的链接。因此，展示的设计对于整体服务的设计至关重要。 你将创建的应用 我们将使用 Spring HATEOAS 构建超媒体驱动的 REST 服务：一个 API 库，可用于创建指向 Spring MVC 控制器的链接，建立资源展示并控制如何将它们呈现为受支持的超媒体格式（例如 HAL）。 该服务将在 http://localhost:8080/greeting 接受 HTTP GET 请求。 它将以问候语的 JSON 展示形式进行响应，该问候语中包含了最简单的超媒体元素，即指向资源本身的链接。以下清单显示了输出： { "content" : "Hello, World!" , "_links" : { "self" : { "href" : "http://localhost:8080/greeting?name=World" } } } 响应已经表明我们可以使用查询字符串中的可选 name 参数来自定义问候语，如下清单所示： http://localhost:8080/greeting?name

REST是所有Web应用都应该遵守的架构设计指导原则。 Representational State Transfer，翻译是”表现层状态转化”。 面向资源是REST最明显的特征，对于同一个资源的一组不同的操作。资源是服务器上一个可命名的抽象概念，资源是以名词为核心来组织的，首先关注的是名词。REST要求，必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。（7个HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS） 什么是RESTful API？ 符合REST架构设计的API。 总结 符合REST设计标准的API，即RESTful API。REST架构设计，遵循的各项标准和准则，就是HTTP协议的表现，换句话说，HTTP协议就是属于REST架构的设计模式。比如，无状态，请求-响应。。。 参考： 理解本身的REST架构风格 http://www.infoq.com/cn/articles/understanding-restful-style/ 理解RESTful架构 http://www.ruanyifeng.com/blog/2011/09/restful.html Restful API设计指南 http://www.ruanyifeng.com/blog/2014/05/restful_api.html 二

在我看来，集成是微服务相关技术中最重要的一个。做得好的话，你的微服务可以保持自 治性，你也可以独立地修改和发布它们；但做得不好的话会带来灾难。希望本章能够帮助 你在微服务之旅中，避免曾经在SOA中遇到的那些问题。 4.1寻找理想的集成技术 微服务之间通信方式的选择非常多样化，但哪个是正确的呢？ SOAP? XML-RPC ? REST? Protocol Buffers ?后面会逐一讨论，但是在此之前需要考虑的是，我们到底希望 从这些技术中得到什么。 4.1.1避免破坏性修改 有时候，对某个服务做的一些修改会导致该服务的消费方也随之发生改变。后面会讨论如 何处理这种情形，但是我们希望选用的技术可以尽量避免这种情况的发生。比如，如果一 个微服务在一个响应中添加了一个字段，那么已有的消费方不应该受到影响。 4.1.2保证API的技术无关性 我很喜欢保持开放的心态，这也正是我喜欢微服务的原因。因此我认为，保证微服务之间 通信方式的技术无关性是非常重要的。这就意味着，不应该选择那种对微服务的具体实现 技术有限制的集成方式。 4.1.3使你的服务易于消费方使用 消费方应该能很容易地使用我们的服务。如果消费方使用该服务比登天还难，那么无论该 微服务多漂亮都没有任何意义。所以让我们考虑一下，如何让消费方简便地使用美妙的新 服务。理想情况下，消费方应该可以使用任何技术来实现，从另一方面来说