第三节：实施REST规范的影响评估

要评估实施REST规范对已有系统和未来系统的影响，首先需要明确REST规范会对哪些方面提出要求和约束。REST规范一般会从两个层次提出要求：第一个层次较为简单，只对网络系统对外提供的服务接口提出约束，要求服务是RESTful的；第二个层次要求更高，即整个系统的架构风格是RESTful的。下面分两种情况来评估REST规范的影响。

要求服务接口是RESTful的

如果只是要求服务接口是RESTful的，对已有系统和新建系统的影响较小。从应用系统角度来分析，现有的系统架构，普遍实现了服务接口和业务逻辑的解耦。即同样的业务逻辑代码，可以在不编程或少量编程的情况下，通过工具软件和框架实现不同服务接口的绑定。从工具软件和框架的角度来分析，现在普遍使用的工具和框架，都是同时支持多种服务接口的绑定的，如WebService和RESTful。如果要求将已有服务暴露成RESTful的接口，只要系统架构合理，工具软件支持，影响并不大。实际上，同样的业务逻辑既提供WebService服务，又提供RESTful服务，也并不鲜见。

我们已有的系统，大部分是以下三种类型：使用C语言开发，使用Tuxedo作为应用服务器的遗留系统；使用Java开发，使用Spring框架，使用Weblogic作为应用服务器的系统；使用.NET框架，使用IIS作为应用服务器的系统。

第一种类型的系统，可以使用Tuxedo的salt组件来支持RESTful，也可以借助ESB来支持RESTful，都不需要对应用系统进行大量的改造，主要的工作都在于配置和测试。

第二种类型的系统，Spring框架就可以通过配置或注解的方式支持RESTful，也不需要大量的系统改造。

第三种类型的系统，.NET框架也提供了RESTful的支持，可以通过配置、注解或简单的接口层改造来实现。

要求整个系统的架构风格是RESTful的

如果要求整个系统的架构风格呢是RESTful的，那么对已有系统和新建系统的影响较大。从第一节的内容来看，如果一个系统的架构要做到RESTful的，必须从多个方面满足REST的原则和约束。包括但不限于以下工作：

• 按照REST的要求，对系统的数据，也就是资源进行划分和设计。具体包括资源有哪些，按照什么粒度进行划分？资源有哪些表述？
• 对资源的标识，也就是URI进行具体的设计，包括各类资源的URI命名，URI的层级等设计。
• 进行无状态改造，实现服务无状态。将状态持久化到数据层，或将状态抽取保存在缓存组件中。
• 进行各项操作的规范改造，包括哪些操作只读，哪些操作可以更新数据，以及各种场景下的返回状态码符合规范。
• 进行必要的缓存设计，并且在其他方面的设计时，要尽量保证资源是可缓存的。
• 进行连接性设计，包括服务的可见性、可连接性，资源之间的连接设计等。
• 进行服务幂等改造。

仅仅从以上列出来的方面来看，对一个已建成系统进行这些改造，已经需要进行全方位的重构，其难度和工作量都是巨大的，不啻于重新设计系统的架构。而且，对于一些遗留系统而言，不仅需要考虑工作量的问题，而是可行性的问题。