如何构建REST风格的网站

Rest 风格的诞生

在 HTTP 协议发展的过程中，提出了很多的规则，但是这些规则有些烦琐，于是又提出了一种风格约定，它便是 Rest 风格。实际上严格地说它不是一种标准，而是一种风格。在现今互联网的世界中这种风格己经被广泛使用起来了 。 尤其是现今流行的微服务中，这样的风格甚至被推荐为各个微服务系统之间用于交互的方式。在这样的风格下对于简易参数则尽量通过网址进行传递。

Rest 风格到底是什么

REST 按其英文名称（Representational State Transfer) 可翻译为表现层状态转换。 首先需要有资源才能表现， 所以第一个名词是“资源”。 有了资源也要根据需要以合适的形式表现资源，这就是第二个名词“表现层”。最后是资源可以被新增、修改、删除等，也就是第三个名词“状态转换”。这就是 REST 风格的三个主要的名词。

Rest 名词解释

• 资源
  它可以是系统权限用户、角色和菜单等，也可以是一些媒体类型， 如文本、图片、歌曲，总之它就是一个具体存在的对象。 可以用一个 URI (统一资源定位符）指向它， 每个资源对应一个特定的URI。要获取这个资源， 访问它的URI即可， 而在 REST 中每一个资源都会对应一个独一无二的 URI。
• 表现层
  有了资源还需要确定如何表现这个资源。可以使用 JSON、 XML 或者其他的形式表现出来比如图片等，但是在现今的互联网开发中， JSON 己经是一种最常用的表现形式。
• 状态转换
  现实中资源并不是一成不变的， 它是一个变化的过程， 一个资源可以经历创建 (create）、 访问 （visit）、 修改（update） 和删除（delete）的过程。 对于 HTTP 协议而言，它是一个没有状态的协议，这也意味着对于资源的状态变化就只能在服务器端保存和变化，不过好在 HTTP 中却存在多种动作来对应这些变化。

REST 风格架构的特点

• 服务器存在一系列的资源，每一个资源通过单独唯一的 URI进行标识
• 客户端和服务器之间可以相互传递资源，而资源会以某种表现层得以展示
• 客户端通过 HTTP 协议所定义的动作对资源进行操作，以实现资源的状态转换

HTTP 的动作

对于资源而言，它存在创建（create）、修改 （update）、访问 （visit） 和删除 （delete） 的状态转换， 对应于 HTTP 行为中的 5 种动作

• GET (VISIT）： 访问服务器资源（一个或者多个资源）。
• POST (CREATE）： 提交服务器资源信息， 用来创建新的资源。
• PUT (UPDATE）：修改服务器己经存在的资源，使用 PUT 时需要把资源的所有属性一并提交。
• PATCH (UPDATE）： 修改服务器已经存在的资源，使用 PATCH 时只需要将部分资源属性提交。 目前来说这个动作并不常用也不普及， 有些 Java 类还不能完全支持它， 所以在现实中使用它需要慎重。
• DELETE (DELETE）： 从服务器将资源删除。

其中 POST 动作对应创建资源， PUT 和 PATCH 对应更新资 源， GET 请求对应访问资源， DELETE 对应删除资源。 对于 HTTP 协议， 还有另外两种不常用的动作行为

• HEAD： 获取资源的元数据。
• OPTIONS： 提供资源可供客户端修改的属性信息。

使用 Spring MVC 开发 REST 风格项目

Spring 对 REST 风格的支持是基于 SpringMVC 设计基础上的， 在 Spring 4.3 之前只能使用＠RequestMapping 设计 URI，在 Spring 4.3 之后则有更多的注解引入使得 REST 风格的开发更为便捷。

Spring MVC 整合 REST

• @GetMapping：对应 HTTP 的 GET 请求，获取资源。
• @PostMapping：对应 HTTP 的 POST 请求，创建资源。
• @PutMapping： 对应 HTTP 的 PUT 请求，提交所有资源属性以修改资源。
• @PatchMapping： 对应 HTTP 的 PATCH 请求，提交资源部分修改的属性。
• @DeleteMapping： 对应 HTTP 的 DELETE 请求，删除服务器端的资源。

处理 HTTP 状态码、异常和晌应头

当发生资源找不到或者处理逻辑发生异常时， 需要考虑的是返回给客户端的 HTTP 状态码和错误消息的问题。 为了简化这些开发 ， Spring 提供了实体封装类 ResponseEntity 和注解＠ResponseStatus。 ResponseEntity 可以有效封装错误消息和状态码，通过 @ResponseStatus 可以配置指定的响应码给客户端。