Hi，大家好，我是编程小6，很荣幸遇见你，我把这些年在开发过程中遇到的问题或想法写出来，今天说一说
restfully_restapi开发框架,希望能够帮助你!!!。

1. 什么是RESTfulAPI

RESTful API 是一种互联网软件架构的设计规范，设计指南，设计风格，设计原则（类似于web标准，并不是标准【规范，原则】）

2. 产生背景

开始开发时，前后端高度融合（耦合）
近些年：前后端分离，前端各种客户端产生。基于这种现状，需要一个统一的机制。为前后端通信服务（API机制） 因此，前后端分离开来前后端基于API 开发，即：面向接口开发 前后端基于接口传递数据。
RESTfulAPI作为制定接口标准的规范而产生了。

3. RESTful API

1. API简介：
   a. 应用程序编程接口（接口）application programming interface
2. API发展历史：
   a. 威尔克斯和惠勒 1951 年出版的《电子数字计算机程序的准备》一书包含了第一个发布的 API 规范。Joshua Bloch认为 Wilkes 和 Wheeler “潜在地发明”了 API，因为它更像是一个被发现而不是发明的概念。
   b. 术语“应用程序接口”（没有-ing后缀）首先记录在 1968 年AFIPS会议上发表的一篇名为远程计算机图形的数据结构和技术的论文中。
   c. CJ Date[8]在 1974 年的一篇名为The Relational and Network Approaches: Comparison of the Application Programming Interface 的论文中将该术语引入数据库领域。
3. 没有RESTful之前，开发人员必须同时具有前后端开发的能力
   前端的工作十分尴尬，因此那个阶段，前端的地位并不是很高。当时的代码也十分混乱，不能访问其他域的数据。后来google带动ajax，兴起前后端分离的思想，API正式兴起，前后端开始各司其职。
4. REST：（一种软件架构风格）
   a. REST 是 REpresentational State Transfer 的首字母缩写，是分布式超媒体系统的一种架构风格 。罗伊菲尔丁于 2000 年在他著名的 论文中首次提出它。

4. RESTful六个指导原则

RESTful 架构的六个指导原则或 约束 是：

4.1. 统一接口

通过将 通用性原则应用于 组件接口，我们可以简化整个系统架构并提高交互的可见性。
多个架构约束有助于获得统一的接口并指导组件的行为。
以下四个约束可以实现统一的 REST 接口：
● 资源标识 ——接口必须唯一标识客户端和服务器之间交互中涉及的每个资源。
● 通过表示操作资源 ——资源在服务器响应中应该有统一的表示。API 使用者应该使用这些表示来修改服务器中的资源状态。
● 自描述消息 ——每个资源表示应该携带足够的信息来描述如何处理消息。它还应该提供客户端可以对资源执行的附加操作的信息。
● 超媒体作为应用程序状态的引擎 ——客户端应该只有应用程序的初始 URI。客户端应用程序应该使用超链接动态驱动所有其他资源和交互。

4.2. 客户端服务器

客户端-服务器设计模式强制 关注点分离，这有助于客户端和服务器组件独立发展。
通过将用户界面关注点（客户端）与数据存储关注点（服务器）分离，我们提高了用户界面跨多个平台的可移植性，并通过简化服务器组件来提高可扩展性。
在客户端和服务器发展的同时，我们必须确保客户端和服务器之间的接口/契约不会中断。

4.3. 无状态

无状态 要求从客户端到服务器的每个请求都必须包含理解和完成请求所需的所有信息。
服务器无法利用服务器上任何先前存储的上下文信息。
因此，客户端应用程序必须完全保持会话状态。

4.4. 可缓存

可 缓存约束 要求响应应隐式或显式地将自身标记为可缓存或不可缓存。
如果响应是可缓存的，则客户端应用程序有权在稍后为等效请求和指定时间段重用响应数据。

4.5. 分层系统

分层系统样式允许通过约束组件行为来由分层层组成架构。
例如，在分层系统中，每个组件都无法看到它们正在与之交互的直接层之外。

4.6. 按需编码（可选）

REST 还允许通过以小程序或脚本的形式下载和执行代码来扩展客户端功能。
下载的代码通过减少需要预先实现的功能数量来简化客户端。服务器可以将部分功能以代码的形式交付给客户端，客户端只需要执行代码即可。

5. 什么是资源？

RESOURCE
URI：统一资源标识符，是一个字符串，用来标识互联网资源的名字
URL：统一资源定位符，他是一种具体的URI

REST 中信息的关键 抽象是资源。我们可以命名的任何信息都可以是资源。例如，REST 资源可以是文档或图像、时间服务、其他资源的集合或非虚拟对象（例如，人）。
资源在任何特定时间的状态称为 资源表示。
资源表示包括：
● 数据_
● 描述数据的 元数据
● 以及 可以帮助客户过渡到下一个所需状态的超媒体链接。
一个 REST API 由一组相互关联的资源组成。这组资源称为 REST API 的 资源模型。

5.1.资源标识符

REST 使用资源标识符来识别客户端和服务器组件之间交互中涉及的每个资源。

5.2. 超媒体

表示的数据格式称为 媒体类型。媒体类型标识了一个规范，该规范定义了如何处理表示。
RESTful API 看起来像 超文本。每个可寻址的信息单元都携带一个地址，或者显式（例如，链接和 id 属性）或隐式（例如，从媒体类型定义和表示结构派生）。
— 罗伊·菲尔丁
超文本（或超媒体）意味着 信息和控制的同时呈现， 使得信息成为用户（或自动机）获得选择和选择动作的可供性。
请记住，超文本在浏览器上不需要是 HTML（或 XML 或 JSON）。当机器了解数据格式和关系类型时，它们可以跟踪链接。

5.3. 自我描述

此外， 资源表示应该是自描述的：客户端不需要知道资源是员工还是设备。它应该根据与资源相关联的媒体类型进行操作。
所以在实践中，我们将创建许多 自定义媒体类型 ——通常是一种媒体类型与一种资源相关联。
每种媒体类型都定义了一个默认处理模型。例如，HTML 定义了超文本的呈现过程以及每个元素周围的浏览器行为。
媒体类型与资源方法没有关系获取/放置/删除/删除/ …除了某些媒体类型元素将定义类似于“具有href属性的锚元素创建一个超文本链接时，某些媒体类型元素的事实在对应于CDATA-encodedhref属性的 URI 上调用检索请求 (GET)。”

6. 资源方法

与 REST 相关的另一个重要的事情是 资源方法。这些资源方法用于在任何资源的两种状态之间执行所需的转换。
很多人错误地将资源方法与 HTTP 方法 （即 GET/PUT/POST/DELETE）相关联。Roy Fielding 从未提及任何关于在何种条件下使用哪种方法的建议。他所强调的只是它应该是一个 统一的界面。
例如，如果我们决定应用程序 API 将使用 HTTP POST 来更新资源——而不是大多数人推荐的 HTTP PUT——那没关系。尽管如此，应用程序界面仍将是 RESTful。
理想情况下，转换资源状态所需的一切都应该是资源表示的一部分——包括所有支持的方法以及它们将以何种形式离开表示。
我们应该输入一个 REST API，除了初始 URI（书签）和一组适合目标受众（即，任何可能使用 API 的客户端都可以理解）的标准化媒体类型之外，没有任何先验知识。
从那时起，所有应用程序状态转换必须由客户端选择的服务器提供的选项驱动，该选项存在于接收到的表示中，或者由用户对这些表示的操作暗示。
转换可以由客户端对媒体类型和资源通信机制的了解来确定（或限制），这两者都可以在运行中得到改进（例如， 按需编码）。[这里的失败意味着带外信息正在推动交互而不是超文本。]

7. REST和HTTP不一样

许多人更喜欢将 HTTP 与 REST 进行比较。 REST 和 HTTP 不一样。
REST！= HTTP
尽管 REST 还打算使 Web（互联网）更加精简和标准，但 Roy fielding 提倡更严格地使用 REST 原则。这就是人们尝试将 REST 与 Web 进行比较的地方。
Roy fielding 在他的论文中没有提到任何实现方向——包括任何协议偏好甚至 HTTP。到目前为止，我们都在遵守 REST 的六项指导原则，我们可以将其称为我们的接口——RESTful。

8. 总结

简而言之，在 REST 架构风格中，数据和功能被视为资源，并使用 统一资源标识符 (URI) 进行访问。
通过使用一组简单的、定义明确的操作对资源进行操作。此外，资源必须与其表示分离，以便客户端可以访问各种格式的内容，例如 HTML、XML、纯文本、PDF、JPEG、JSON 等。
客户端和服务器通过使用标准化的接口和协议来交换资源的表示。通常 HTTP 是最常用的协议，但 REST 并不强制要求它。
有关资源的元数据可用并用于控制缓存、检测传输错误、协商适当的表示格式以及执行身份验证或访问控制。
最重要的是，与服务器的每次交互都必须是无状态的。
所有这些原则都有助于 RESTful 应用程序变得简单、轻量和快速。

今天的分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。