一、API

API，英文全称Application Programming Interface，翻译为"应用程序编程接口"。就是将一些功能（逻辑）封装成组件，目的是提供一个应用程序接口给其它程序与开发人员访问，而这些访问人员不需要访问源码以及理解内部工作原理就可以直接使用。

例如在WEB项目中A应用暴露一个请求映射方法，B应用通过调用这个请求映射方法从而得到对应功能（请求映射方法赋予的功能）。

二、RESTful

RESTFUL是一种网络应用程序的设计风格和开发方式，基于HTTP，可以使用 XML 格式定义或 JSON 格式定义。最常用的数据格式是JSON。由于JSON能直接被JavaScript读取，所以，使用JSON格式的REST风格的API具有简单、易读、易用的特点。

注意：RESTful不是标准，它只是提出了一组客户端和服务器交互时的架构理念和设计原则，基于这种理念和原则设计的接口可以更简洁，更有层次。

2.1 RESTful发展历史

RESTful 架构风格的发展历史紧密关联于互联网和Web服务的演变。以下是RESTful架构发展的几个关键时间点和里程碑：

2000年：REST架构风格由Roy Fielding在他的博士论文中首次提出。Fielding是HTTP/1.1和URI规范的主要作者之一，他在论文中定义了REST原则作为理解和设计网络架构的一种方式。REST的提出是为了解决Web服务接口设计中的复杂性和低效率问题。
2000年代初：REST开始被Web开发社区接受，并逐渐应用于Web服务的设计中。这个时期，Web服务主要由SOAP（Simple Object Access Protocol）协议和基于XML的服务定义。尽管SOAP提供了丰富的功能，但它的复杂性和重量级实现使得开发人员开始寻找更简单的替代方案。
2005年左右：随着Web 2.0时代的到来，RESTful API开始获得更广泛的认可和应用。Web 2.0强调使用Web作为平台，促进用户之间的交互和协作，这需要更灵活和轻量级的API。RESTful API以其简单性、易于使用和基于标准HTTP操作的特点，成为许多Web应用和服务的首选架构。
2010年代：随着移动设备和云计算的兴起，RESTful API成为构建Web服务和移动应用后端的事实标准。大量的互联网服务，包括社交网络、在线购物和地图服务等，都通过RESTful API对外提供服务。此外，新的数据格式（如JSON）成为与RESTful API交互的首选，因为它比XML更轻量级，更易于解析。
至今：RESTful API继续是Web服务和应用程序接口设计的主流方法。同时，出现了一些新的技术和架构风格（如GraphQL和gRPC）来解决RESTful API在某些场景下的局限性，但REST仍然是许多系统架构和API设计的基础。

总体上，RESTful架构的发展受益于其基于标准HTTP协议的简单性和无状态性，这使得它能够与Web的原生技术无缝集成，并支持广泛的客户端和服务端技术。随着互联网技术的发展，RESTful架构不断适应新的需求和挑战，保持其在现代Web服务设计中的重要地位。

2.2 RESTfull特点

RESTfull架构风格的特点如下所示：

资源（Resources） ：RESTful架构的核心概念是资源。在REST中，所有的数据或服务都被视为资源，每个资源都有一个唯一的标识符（通常是URI）用于标识和访问。
表现层（Representation） ：资源的状态以某种形式进行表达，这可以是XML、JSON、HTML等格式。客户端和服务器之间通过这些表现层来交换信息。例如，一个用户资源可以以JSON格式表示，包含用户的姓名、电子邮件等信息。
状态无关（Stateless） ：REST是一种状态无关的架构，即每个请求都包含足够的信息，使服务器能够理解和处理请求。服务器不存储客户端的状态，每个请求都是独立的，服务器不需要维护关于客户端的任何信息。
统一接口（Uniform Interface） ：RESTful架构具有统一的接口，这是其设计的核心原则之一。这个接口简化了系统的架构，使不同部分可以独立演化。统一接口的关键特征包括资源标识符、资源操作的标准化（例如HTTP方法如GET、POST、PUT、DELETE等）以及通过表现层来传递资源的状态。
无状态通信（Stateless Communication） ：通信是无状态的，每个请求从客户端到服务器都必须包含所有必要的信息。服务器不应该存储关于客户端状态的信息，从而使得系统更加可伸缩和可靠。
可缓存性（Cacheability） ：为了提高性能，RESTful服务可以使用HTTP协议中的缓存机制。服务器可以指定哪些响应可以被缓存，客户端可以缓存这些响应以减少对服务器的请求。这对于减轻服务器负载和提高性能非常重要。
按需可扩展性（Layered System） ：RESTful架构允许系统以分层方式进行构建。每一层都提供特定的功能，且对于上层来说，下层的实现是透明的。这种分层的设计使得系统更容易理解、更易于扩展，并且有助于提高系统的灵活性。

2.3 资源

RESTfull 是面向资源的，每个资源都有一个唯一的资源标识符（URI）。每个URI代表一种资源（resource），所以URI中不能有动词，只能有名词，而且所用的名词往往与数据库的表名对应。一般来说，数据库中的表都是同种记录的"集合"（collection），所以URI中的名词也应该使用复数。

less 复制代码

// 查询所有员工

@RequestMapping(value = "/users", method = RequestMethod.GET)

@ResponseBody

public List<User> list() {

    ...

}

2.4 请求方式

RESTful API 定义了一组常用的 HTTP 方法来执行不同类型的操作。这些方法通常与 CRUD 操作（创建、读取、更新、删除）对应，以及其他一些常见操作：

GET：用于获取资源的信息。GET 请求不会对服务器上的资源进行修改，仅用于获取资源的状态信息。
POST：用于创建新的资源。客户端可以通过 POST 请求向服务器提交数据，以创建新的资源。通常在创建新记录、提交表单或执行其他类似操作时使用。
PUT：用于更新现有资源或创建新资源。PUT 请求用于将指定的资源的状态更新为请求中包含的数据。如果资源不存在，则可以创建一个新资源。
PATCH：用于部分更新资源的信息。PATCH 请求类似于 PUT 请求，但是它只更新资源的部分属性，而不是整个资源。
DELETE：用于删除指定的资源。DELETE 请求会从服务器上删除指定的资源。
OPTIONS：用于获取目标资源支持的通信选项。客户端可以通过发送 OPTIONS 请求来了解服务器对资源支持的 HTTP 方法。
HEAD：与 GET 请求类似，但是服务器只返回响应头，不返回实际数据。HEAD 请求通常用于检查资源的元数据，如检查资源是否存在或是否被修改。

2.5 RESTfull&传统模式

假设现在前端需要调用url去操作User资源，那么我们使用传统模式和RESTfull架构风格来比较这两中模式。

2.5.1 查询

如果我们想要查询所有用户信息：http://localhost:8093/user/list（传统）、http://localhost:8093/user/list（RESTfull）；

如果要根据单个id去查询用户数据：http://localhost:8093/user/list？id=1023（传统）、http://localhost:8093/users/1023（RESTfull）；

注意：对于查询传统模式和RESTfull风格都是使用GET类型请求。

注意：我们在使用RESTfull风格进行开发的时，若当参数非常多时就不建议将参数放于路径中，若一些参数名非常敏感，建议可以使用参数路径方式，可以隐藏参数名。

2.5.2 添加

如果我们想要添加一条用户信息：http://localhost:8093/user/add（传统）、http://localhost:8093/users（RESTfull）；

注意：对于添加操作传统模式和RESTfull风格都是使用POST类型请求。

2.5.3 修改

如果我们想要去修改某个用户的信息：http://localhost:8093/user/update（传统）、http://localhost:8093/users（RESTfull）；

注意：对于修改操作传统模式使用POST类型请求，而RESTfull风格则可以使用PUT类型请求。

2.5.4 删除

如果我们想要删除某个用户的数据：http://localhost:8093/user/delete（传统）、http://localhost:8093/users（RESTfull）；

注意：对于删除操作传统模式使用POST类型请求，而RESTfull风格则可以使用DELETE类型请求。

RESTful详解