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