基于Java的REST架构风格及接口安全性设计的讨论

1.REST即表现层状态传递（Representational [,rɛprɪzɛn'teʃnl] State Transfer，简称REST）。

（1）REST名词解释：

通俗来讲就是资源在网络中以某种表现形式进行状态转移。分解开来：

Resource：所指的不只是数据，而是数据和表现形式的组合；

Representational：某种表现形式，比如用JSON，XML，JPEG等；

State Transfer：状态变化。通过HTTP动词实现。

（2）RESTful API：

REST(表述性状态转移)是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是RESTful。

参考博文：

http://www.ruanyifeng.com/blog/2014/05/restful_api.html

 

 

2.Java中实现RESTful API的主流框架：

l Jersey

l RESTEasy

l Restlet

l Apache CXF

以上几个均为基于JAX-RS的实现，在性能测试中，JBoss的RESTEasy吞吐率最好，SUN的Jersey其次，CXF、Restlet最差。（网评）

 

 

3.满足HATEOAS（超媒体作为应用状态的引擎 Hypermedia As The Engine Of Application State）约束的REST实现，使用Spring Data项目中的以下几个子项目：

(1)spring-data-rest并没有真正的实现JAX-RS（Java API for RESTful Web Services）规范。

其中JAX-RS是Oracle的Java EE 6的技术，与Spring开源平台下的框架有所不同。

(2)Spring Data JPA 是 Spring 基于 ORM 框架、JPA 规范的基础上封装的一套JPA应用框架，可使开发者用极简的代码即可实现对数据的访问和操作。

此外，Spring Data还包括包括非关系数据库、Map-Reduce 框架、云数据服务等等；

 

HATEOAS（Hypermedia as the engine of application state）是 REST 架构风格中最复杂的约束，也是构建成熟 REST 服务的核心。REST 成熟度模型把 REST 服务按照成熟度划分成 4 个层次：

• 第一个层次（Level 0）的 Web 服务只是使用 HTTP 作为传输方式，实际上只是远程方法调用（RPC）的一种具体形式。SOAP 和 XML-RPC 都属于此类。
• 第二个层次（Level 1）的 Web 服务引入了资源的概念。每个资源有对应的标识符和表达。
• 第三个层次（Level 2）的 Web 服务使用不同的 HTTP 方法来进行不同的操作，并且使用 HTTP 状态码来表示不同的结果。如 HTTP GET 方法来获取资源，HTTP DELETE 方法来删除资源。
• 第四个层次（Level 3）的 Web 服务使用 HATEOAS。在资源的表达中包含了链接信息。客户端可以根据链接来发现可以执行的动作。

 

从上述 REST 成熟度模型中可以看到，使用 HATEOAS 的 REST 服务是成熟度最高的，也是推荐的做法。对于不使用 HATEOAS 的 REST 服务，客户端和服务器的实现之间是紧密耦合的。客户端需要根据服务器提供的相关文档来了解所暴露的资源和对应的操作。当服务器发生了变化时，如修改了资源的 URI，客户端也需要进行相应的修改。而使用 HATEOAS 的 REST 服务中，客户端可以通过服务器提供的资源的表达来智能地发现可以执行的操作。当服务器发生了变化时，客户端并不需要做出修改，因为资源的 URI 和其他信息都是动态发现的。

 

参考：https://spring.io/guides/gs/accessing-data-rest/

 

4.接口的安全性设计：

(1)使用HTTPS加密传输。

非对称加密技术：服务端生成一把给服务端自己用的私钥，一把给客户端使用的公开的公钥。原则是只有私钥能打开公钥，公钥能打开私钥，其中一种经典的实现叫RSA算法。

1. 客户端向服务器索取公钥 PublicKey；
2. 服务器将公钥发给客户端（这里没有保密需求，因为公钥是向所有人公开的）；
3. 客户端使用服务器的公钥 PublicKey 把 Pre-Master-Key 加密成密文，传送给服务器；
4. 服务器用私钥 PrivateKey 解密密文，获取到客户端发送的 Pre-Master-Key;

其中的第二步容易出现被中间人拦截伪造公钥，这又如何解决？

需要服务端给客户端发送一个证书，上面记载了服务器的域名，公钥，单位，签发机关，有效期等。

但是，又如何保障证书的安全？

其中一种防伪手段就是加签名，只要有权威机构的签名，就可以确认证书是真是的。而计算机的数字化签名也是使用非对称加密技术，具体不再详述。

 

*(2)身份认证：使用JWT（无状态分布式授权，支持各类语言） / OAuth 2.0等。

JWT原理图：

 

参考博文 http://blog.leapoahead.com/2015/09/07/user-authentication-with-jwt/

 

*(3)权限管理：Apache Shiro（不依赖Web环境）、Spring Security等。

可以看到：应用代码直接交互的对象是Subject，也就是说Shiro的对外API核心就是Subject；其每个API的含义：

Subject：主体，代表了当前“用户”，这个用户不一定是一个具体的人，与当前应用交互的任何东西都是Subject，如网络爬虫，机器人等；即一个抽象概念；所有Subject都绑定到SecurityManager，与Subject的所有交互都会委托给SecurityManager；可以把Subject认为是一个门面；SecurityManager才是实际的执行者；

SecurityManager：安全管理器；即所有与安全有关的操作都会与SecurityManager交互；且它管理着所有Subject；可以看出它是Shiro的核心，它负责与后边介绍的其他组件进行交互，如果学习过SpringMVC，你可以把它看成DispatcherServlet前端控制器；

Realm：域，Shiro从从Realm获取安全数据（如用户、角色、权限），就是说SecurityManager要验证用户身份，那么它需要从Realm获取相应的用户进行比较以确定用户身份是否合法；也需要从Realm得到用户相应的角色/权限进行验证用户是否能进行操作；可以把Realm看成DataSource，即安全数据源。

(4)安全过滤：包括防止一些SQL注入、XSS、XXE、XSRF漏洞等。

(5)速度限制：限制某段时间内用户请求次数。

(6)错误处理：非法操作记录和处理。

(7)参数加密：接口参数加密+时效性验证+私钥，如：腾讯开放平台的OpenAPI。

 

 

5.讨论与总结：

(1)REST相比于传统SOAP的优势？

• 可以利用缓存Cache来提高响应速度
• 通讯本身的无状态性可以让不同的服务器处理一系列请求中的不同请求，提高服务器的扩展性
• 浏览器即可做客户端，简化软件开发的需求
• 相对于其他叠加的HTTP协议之上的机制，REST的软件依赖性更小
• 不需要额外的资源发现机制
• 在软件技术演进中的长期的兼容性更好

 

SOAP并不假定传输数据的下层协议，因此必须设计为能在各种协议上运行。即使绝大多数SOAP是运行在HTTP上，使用URI标识服务，SOAP也仅仅使用POST方法发送请求，用一个唯一的URI标识服务的入口。当然SOAP也有其自己适用的场景，在安全性、原子性事务、消息可靠性方面有自己独特的优点。

 

(2)REST设计的核心是什么？

1. 资源（Resource）

这个讨论有争议，有人提出REST并不是围绕资源而设计的，而是一种为”建立十年内不过时的软件系统架构“而建立的一种架构风格，也有人认为REST设计是以系统资源为中心的Web服务，如“最新访问的10位会员”和“最活跃的10位会员”在数据上可能有重叠或者完全相同，而由于他们的表现形式不同，所以被归为不同的资源。

1. 资源的表现形式（Representation）

比如用JSON，XML，JPEG等；

1. 状态转移（State Transfer）

一般地，GET/POST/PUT/DELETE即可满足。

1. 统一接口（Uniform Interface）

对资源使用一致的命名规则（naming scheme）,使用唯一、全局统一的命名规则的好处，既适用于浏览器中的Web应用，也适用于机对机（machine-to-machine，m2m）通信。

1. 超文本驱动（Hypertext Driven）

“超媒体作为应用状态的引擎（Hypermedia as the engine of application state）”，有时简写为HATEOAS。严格地说这个描述的核心是超媒体概念，换句话说：是链接的思想。

应用程序（已经检索过文档）如何“跟随”链接检索更多的信息。当然，如果使用一个遵守专用命名规范的简单“id”属性作为链接，也是可行的——但是仅限于应用环境之内。使用URI表示链接的优雅之处在于，链接可以指向由不同应用、不同服务器甚至位于另一个大陆上的不同公司提供的资源——因为URI命名规范是全球标准，构成Web的所有资源都可以互联互通。

超媒体原则还有一个更重要的方面——应用“状态”。简而言之，实际上服务器端（如果你愿意，也可以叫服务提供者）为客户端（服务消费者）提供一组链接，使客户端能通过链接将应用从一个状态改变为另一个状态。

对此原则总结如下：任何可能的情况下，使用链接指引可以被标识的事物（资源）。

 

(3)REST的应用场景？

 

如腾讯开放平台REST API导航图：