如何理解 CRUD 与 REST

如何理解 CRUD 与 REST

码匠 · 10 minute read
  1. 什么是 CRUD?
  2. CRUD 的发展简史
  3. CRUD 规则
  4. 什么是 REST?
  5. REST 的发展简史
  6. REST 规则
  7. CRUD VS REST
  8. 相同点
  9. 不同点
  10. 关于码匠

CRUD 和 REST 是应用开发领域中两个比较常见的概念,但由于二者之间概念存在重叠而常常被混淆。简单来说,REST 是一种软件架构风格,是一种针对网络应用的设计和开发方式。而 CRUD 是一个缩写,指的是数据库中可以执行的四种基本操作:创建 (Create)、读取 (Read)、更新 (Update) 和删除 (Delete)。本篇文章码匠将带大家深入了解二者的异同以及具体使用过程中的注意事项。

什么是 CRUD?

CRUD 是来自于编程领域的缩写,它指的是被认为是实现持久性存储应用的四个功能:创建、读取、更新和删除。但是,现如今 CRUD 常作为「CRUD 应用」出现,「CRUD 应用」指的是通过一个网络应用或移动应用的用户界面,进行创建、读取、更新和删除信息的操作。

码匠提供图形界面形式的查询设置

CRUD 的发展简史

CRUD 问世于 20 世纪 80 年代,用于描述 SQL 中的数据库基本操作。首次提及是在 1990 年 Haim Kilov 的文章《从语义到面向对象的数据建模》中,后来在 1983 年 James Martin 所著的《管理数据库环境》一书中首次广为人知。

CURD 设计之初是为了增强数据库的持久性存储,而在现代软件开发中,它又为 SQL、DDS 和 HTTP 协议等应用程序提供了设计原则。

CRUD 规则

从创建到删除,CRUD 基本包含一个循环的概念:

  1. 创建 (CREATE) 用来添加一项或多项纪录,在数据库中表现为通过 INSERT 语句生成新的记录。

  2. 读取 (READ) 则是根据不同的参数检索数据,相当于 SQL 中的 select 语句。

  3. 更新 (UPDATE) 过程用于更新和修改纪录。

  4. 删除 (DELETE) 过程为删除一项或多项纪录。

CRUD 后来还出现了其他变形:

  1. CRUDL:创建 (create)、读取 (read)、更新 (update)、删除 (delete)、列表 (listing)

  2. BREAD:浏览 (browse)、读取 (read)、编辑 (edit)、添加 (add)、删除 (delete)

  3. DAVE:删除 (delete)、添加 (add)、预览 (view)、编辑 (edit)

  4. CRAP:创建 (create)、复制 (replicate)、追加 (append)、处理 (process)

什么是 REST?

REST 协议的创始人Roy Fielding 将 REST 描述为分布式超媒体系统内架构元素的抽象化。REST 架构风格为网络系统开发提供了统一的标准,并规定了系统的互动方式。

REST 的发展简史

时间推回 2000 年,这个时候开发人员并没有一个用来开发网络 API 的标准,他们自创了一大堆不同的协议,这些协议大都复杂繁琐、难以执行。于是 Roy Fielding 和他的同事一起开发了 REST 协议,进而允许两个服务器能在全球范围内交换数据。

符合 REST 的系统被称为 RESTful 系统。这些系统的特点是无状态性以及客户端和服务器的分离。自 2000 年推出以来,REST 已经被用于各种公司各种行业。

REST 规则

REST 有六个约束条件:

1. 统一接口

RESTful 架构所遵循的统一性原则禁止在一个 API 中使用多个独立接口。通过简化和解耦架构,每个部分都可以独立发展。统一接口的四个指导原则是:

  • 资源识别:每个资源都有一个资源标识,且每个资源的资源标识可以用来唯一地标明该资源。

  • 通过表述来操作资源:这里的表述是对自身的表述,也就是说一个 REST 系统所返回的资源需要能够描述自身并提供足够的用于操作该资源的信息,比如如何对资源进行 CRUD 等操作。换句话说,一个 REST 服务不需要额外的文档对如何操作资源进行说明。

  • 自描述的信息:在 REST 系统中传递消息时还要能提供自身如何被处理的信息。例如该消息所使用的 MIME 类型,是否可以被缓存等。

  • 超媒体作为应用状态的引擎:客户端通过协议主体内容、查询字符串参数、请求头和请求 URI(资源名称)传递状态。服务端通过协议主体内容、状态码和响应头向客户提供状态。

2. 客户/服务器模型(CS 架构)

通信只能由客户端单方面发起,表现为请求-响应的形式。客户-服务器模型约束背后的原则是关注点的分离,即分离用户界面和数据存储两个关注点。这有助于客户端和服务器的独立发展,同时改善了用户界面跨平台的可移植性和可扩展性。

3. 无状态

无状态规定,从客户端到服务器的每个请求必须包含理解和完成该请求所需的全部信息,不能利用任何存储在服务器端的上下文,所以,会话状态要全部保存在客户端。

4. 缓存

缓存是为了改善网络效率而提出的,缓存要求服务器的响应中的数据被隐式地或显式地标记为可缓存或不可缓存。例如,如果响应是可缓存的,那么以后再遇到相同的请求该相应数据可重复利用。

5. 分层系统

分层系统通过限制层次之间的行为(例如每一层对其他层都是只读的)来将架构分解为若干层级。每个层级之间都有一定的独立性,中间层次还支持通过实现负载平衡和共享缓存来提高系统的可扩展性。

6. 按需代码(Code-On-Demand 可选)

客户端可以下载运行服务端传来的代码(比如 JavaScript)通过减少一些功能简化了客户端。

CRUD VS REST

相同点

CRUD 的每个操作都可以被映射到 DDS、SQL 和 HTTP 协议中。HTTP 协议是 RESTful 架构中资源之间的联系,是 REST 基础的核心部分。而 REST 架构被用来在 Web 应用中执行 CRUD 操作。CRUD 操作与 HTTP 协议的映射:

看似 CRUD 和 REST 存在基本指令的重叠,但应该注意的是,REST 并不简单地等同于 CRUD,RESTful 架构也不仅仅意味着映射 GET、PUT、POST 命令。

不同点

CRUD 主要被用于描述软件系统中数据库或者持久层的基本操作功能。而 REST 架构的核心理念是使用 HTTP 作为应用协议操作网络资源,并且以超媒体作为应用状态转移的载体。

关于码匠

码匠是国内一款面向开发者的低代码平台,我们为将您提供一种更便捷的数据可视化方式。相较于国外开发的 HRM/Admin/CRM/CMS 等后台工具,我们的 UI 界面设计更加适合国内业务场景。同时我们还整合了多款国内常见数据源,包括飞书、企业微信、钉钉、阿里云 OSS 等。不仅如此,我们还一站式提供了企业内部系统常用的租户管理、细粒度的权限控制、审计日志等功能,让您快速搭建后台应用的同时,也为您的企业信息安全保驾护航。

我们的创始团队来自谷歌、快手、百度等公司,深刻理解快速迭代的软件系统对业务的重要性和当下软件开发的复杂性,我们认为在未来软件不会是从零开发的,于是我们重新思考,创造新的工具,帮助公司更好更快地开发软件。

想要了解更多,欢迎来亲自探索