REST 101开发人员专用

本地代码执行

诸如C之类的高级语言中的函数将被汇编为Assembly中的过程。它们增加了一个间接级别，使我们不必考虑内存地址。

诸如Java之类的面向对象语言中的方法和多态性增加了另一种间接性，使我们不必考虑一组相似功能的特定变体。

尽管有这些间接方式，但方法基本上仍然是过程调用，告诉计算机将执行流从一个内存位置切换到另一个内存位置。所有这些都是在同一台计算机上运行的同一进程中发生的。

远程执行代码

这与将执行切换到另一个进程或另一台计算机根本不同。特别是后者非常不同，因为另一台计算机甚至可能没有相同的操作系统，程序可以通过该操作系统访问内存。

因此，尝试尽可能隐藏这种差异的远程代码执行机制（例如RMI或SOAP ）在很大程度上失败并不奇怪。这种技术采用了所谓的远程过程调用（RPC）。

我们必须区分本地过程调用和远程过程调用的原因之一是RPC的速度慢得多。

对于大多数实际应用程序，这将改变您进行的调用的性质：您将希望进行较少的远程调用，而这些调用的粒度更粗。

另一个原因是本质上组织性比技术性强。

当您调用的代码位于另一台计算机上的另一个进程中时，该另一个进程很可能是由其他人编写和部署的。为了使这两段代码能够很好地协作，需要某种形式的协调。这就是我们为耦合付出的代价。

通过界面协调变更

我们还可以在单个过程中看到此问题，例如，当代码部署在不同的jar文件中时。如果升级代码所依赖的第三方jar文件，则可能需要更改代码以使一切正常。

这种协调令人讨厌。如果我们只需部署该jar的最新安全补丁程序而不必担心破坏我们的代码，那就更好了。幸运的是，如果我们谨慎的话，我们可以。

Java之类的语言接口将代码的公共部分和私有部分分开。

客户所依赖的是公共部分，因此您必须以谨慎的方式开发接口，以避免破坏客户。

相反，私有部分可以随意更改。

从界面到服务

在OSGi中，接口是所谓的微服务的基础。通过在注册表中发布服务，我们可以使客户端无需知道哪个对象实现了给定的接口。换句话说，客户端可以发现提供服务的对象的身份。服务注册表成为我们访问功能的入口。

这些接口被称为微服务是有原因的：它们是构成面向服务的体系结构（SOA）的服务的微型版本。

将微服务直接扩展到“ SOA服务”会导致RPC样式的实现，例如使用SOAP。但是，我们早先已经确定RPC不是调用远程代码的最佳方法。

输入REST。

RESTful服务

代表性状态转移（REST）是一种体系结构样式，将Web的优点带入了程序世界。

不能否认Web的可伸缩性，因此这是一个有趣的角度。

与其解释REST通常通过探索其体系结构约束来完成，不如将其与微服务进行比较。

设计良好的RESTful服务具有单个入口点，例如微服务注册表。该入口点可以采用家庭资源的形式。

我们像访问任何其他资源一样访问主页资源：通过表示。表示形式是我们需要解释的一系列字节。这种解释的规则由媒体类型给出。

如今，大多数RESTful服务都基于JSON或XML表示。资源的媒体类型与对象的接口进行比较。

一些接口包含使我们能够访问其他接口的方法。同样，资源的表示形式可能包含指向其他资源的超链接。

基于代码的服务与基于数据的服务

REST和SOAP之间的区别现在变得显而易见。

在SOAP中，就像在微服务中一样，该接口由方法组成。换句话说，它是基于代码的。

另一方面，在REST中，接口由代码和数据组成。我们已经看过数据：媒体类型描述的表示形式。该代码是统一接口，这意味着所有资源都相同（统一）。

实际上，统一接口由HTTP方法 GET，POST，PUT和DELETE组成。

由于统一接口对于所有资源都是固定的，因此任何RESTful服务中的真正汁液都不在代码中，而在数据中：媒体类型。

正如有发展Java接口的规则一样，也有发展媒体类型的规则，例如，基于XML的媒体类型。（由此得出结论，您不能对基于XML的媒体类型使用XML模式验证。）

统一资源标识符

到目前为止，我还没有提到统一资源标识符（URI）。许多所谓的RESTful服务的文档可能会让您觉得它们很重要。

但是，由于URI标识资源，因此它们在微服务中的等效项是实现接口的对象的标识。

希望这表明客户端不必关心URI。仅本地资源的URI很重要。

家庭资源的表示形式包含指向其他资源的链接。这些链接的含义由链接关系指示。

通过了解链接关系，客户端可以决定要遵循的链接，并从表示形式中发现其URI。

服务版本

我们应尽可能遵循不断发展的媒体类型的规则，而不引入任何重大变化。

但是，有时这是不可避免的。然后，我们应该创建该服务的新版本。

由于URI不是RESTful API的公共接口的一部分，因此它们不是中继版本信息的正确工具。可以通过与微服务进行比较来得出指示API主要（即不兼容）版本的正确方法。

每当服务引入重大更改时，都应更改其接口。在RESTful API中，这意味着更改媒体类型。然后，客户端可以使用内容协商来请求其理解的媒体类型。

你怎么看？

可以轻松获得有关如何设计和记录基于代码的接口的文献。

对于基于数据的接口（如媒体类型），情况并非如此。

随着RESTful服务变得越来越流行，这是需要填补的空白。以后我会回到这个话题。

您如何设计服务？您如何记录它们？

参考： REST 101对于我们的JCG合作伙伴 Remon Sinnema的开发人员，请访问安全软件开发博客。

翻译自: https://www.javacodegeeks.com/2013/09/rest-101-for-developers.html