图灵学院 java高级架构师教程
本文将重点介绍REST API的可发现性，HATEOAS以及由测试驱动的实际场景。
为什么要使API可发现
API的可发现性是一个没有得到足够值得关注的主题，因此很少有API能够正确使用它。如果正确完成，它也可以使API不仅具有RESTful和可用性，而且还具有优雅性。
要了解可发现性，您需要了解作为应用程序状态引擎（HATEOAS）的超媒体约束; REST API的这种约束是关于来自超媒体（真正的超文本）的资源上的动作/转换的完全可发现性，作为应用程序状态的唯一驱动因素。
如果API通过会话本身来驱动交互，具体来说就是通过Hypertext，则不会有文档，因为这会强制客户端做出实际上在API上下文之外的假设。
总之，服务器应该具有足够的描述性，以指示客户端如何仅通过超文本使用API，在HTTP会话的情况下，可以是链接头。
可发现方案（由测试驱动）
那么REST服务可被发现意味着什么呢？在本节中，我们将测试使用JUnit测试可发现性的各个特征。由于REST服务已被安全保护，因此每个测试首先需要在使用API之前进行身份验证。
发现有效的HTTP方法
使用无效的HTTP方法使用REST服务时，响应应该是405 METHOD NOT ALLOWED; 此外，它还应该帮助客户端使用响应中的Allow HTTP Header来发现该特定Resource允许的有效HTTP方法：
发现新创建资源的URI
创建新资源的操作应始终使用Location HTTP Header 包含响应中新创建的资源的URI 。如果客户端对该URI执行GET，则该资源应该可用：
测试遵循一个简单的场景：创建一个新的Foo资源，并使用HTTP响应来发现现在可以访问资源的URI。然后测试更进一步，在该URI上执行GET以检索资源并将其与原始资源进行比较，以确保它已被正确保留。
发现获取该类型的所有资源的URI
当我们获取任何特定的Foo资源时，我们应该能够发现我们接下来可以做什么：我们可以列出所有可用的Foo资源。因此，检索资源的操作应始终在其响应中包含URI，以获取该类型的所有资源，再次使用链接头：
请注意，此处显示了extractURIByRel的完整低级代码- 负责通过rel关系提取URI 。
此测试涵盖REST中链接关系的棘手主题：检索所有资源的URI使用rel=”collection”语义。
这种类型的链接关系尚未标准化，但已被多个微格式使用并提议用于标准化。使用非标准链接关系开启了关于RESTful Web服务中微格式和更丰富语义的讨论。
其他潜在的可发现URI和微格式
其他URI可能通过链接头发现，但只有现有的链接关系类型允许，而不会转移到更丰富的语义标记，如定义自定义链接关系，Atom发布协议或微格式，这将是主题另一篇文章。
例如，客户端应该能够在对特定资源执行GET时发现URI以创建新资源; 遗憾的是，模型创建语义没有链接关系。幸运的是，标准做法是创建的URI与获取该类型的所有资源的URI相同，唯一的区别是POST HTTP方法。
案例结论
我们已经看到REST API是如何从根中完全发现的，并且没有先验知识 - 这意味着客户端能够通过在根上执行GET来导航它。继续前进，所有状态更改都由客户端使用REST API在表示中提供的可用和可发现的转换（因此是Representational State Transfer）来驱动。
本文介绍了REST Web服务上下文中可发现性的一些特征，讨论了HTTP方法发现，创建和获取之间的关系，发现获取所有资源的URI等。
尽管Java架构师学习路线已经分享给大家，但有多少人能认真的去践行，这个就难说了。互联网寒冬已经到来，作为程序员，更应在此时提高自己，有着更高远的追求。
篇幅有限，如果需要更详细的java架构师学习路线资料可加博主qq：1993712276，或者去图灵官网查看