RESTful API 是现代化 Web API 开发的常用方式之一，也被广泛应用于前端开发中。然而，在一些并发请求的情况下，RESTful API 的行为可能变得难以预测。本文将探讨如何解决 RESTful API 中的并发请求问题，详细介绍其原因和实现方法，并提供示例代码供参考。
问题背景
在 RESTful API 中，我们使用 HTTP 协议进行数据传输。由于 HTTP 协议中的状态无法长期保存，每个请求都应该是独立的。在一个请求结束后，服务器会返回一个响应，以告知客户端当前的资源状态。
然而，在并发请求的情况下，两个或多个请求可能会同时修改同一个资源，导致其状态变得不可预测。具体来说，当客户端执行了一条“读写更新”（read-modify-write）命令时，如 PUT 或 PATCH，服务器上的并发请求可能导致命令执行失败，或者修改的资源状态与预期不符。
例如，客户端发送一个 PATCH 请求，将一个资源的某个字段从 "true" 改为 "false"：
-- -------------------- ---- -------
----------------------------- -
------- --------
-------- -
--------------- ------------------
--
----- ----------------
------ -----
--
--然而，在客户端发送请求的过程中，另一个并发请求已经修改了相同资源的相同字段，将其从 "true" 改为了 "null"。此时 PATCH 请求会将 field 值修改为 false，覆盖了其他请求所作出的修改，导致资源状态与预期不符。
解决办法
针对以上并发请求问题，我们可以采用以下方法进行解决：
1. 增加版本号
在资源的表示中加入一个版本号，如下所示：
{
"id": 1,
"field": "true",
"version": 1
}每次客户端对该资源进行修改时，都需要指定当前的版本号。如果当前版本号与客户端指定的版本号不匹配，则修改操作失败。通过加入版本号进行控制，对于并发请求，只有最后成功修改的资源的版本号才会被更新，从而避免了并发请求的冲突。
具体来说，客户端发送一个 PATCH 请求时，需要在请求头中指定当前的版本号，如下所示：
-- -------------------- ---- -------
----------------------------- -
------- --------
-------- -
--------------- -------------------
----------- ---
--
----- ----------------
------ -----
--
--服务器需要验证当前资源的版本号与客户端指定的版本号是否一致，如果不一致，则返回 409（Conflict）错误码，提示客户端当前尝试修改的资源版本已过期。
-- -------------------- ---- -------
--------------------------------- ----- ---- -- -
----- -------- - -- ---------- ---
-- ------------------------ --- ----------------- -
----------------------
-------- --------
---
-------
-
-- -------------- --
-------------------
---2. 采用悲观锁
在执行 RESTful API 的操作前，采用悲观锁对资源进行加锁，从而保证同一时间只能有一个客户端修改该资源。当加锁后，其他客户端的请求会进入排队等待，直到当前操作完成并释放锁。
具体来说，服务器端采用数据库悲观锁的方式对资源进行加锁，阻止其他请求对该资源进行修改。只有当前请求完成并释放锁后，其他客户端的请求才能进行。
-- -------------------- ---- -------
--------------------------------- ----- ----- ---- -- -
-- -- --
----- -------- - ----- ------------------
------ - --- ----------- --
----- ----
---
-- ------------- --
----- -----------------
------ -----
---
-- ------------- --
----- ------------------
-------------------
---3. 采用乐观锁
与悲观锁不同，乐观锁的方式是不阻塞其他操作，而是在每次操作前获取当前资源的版本号，然后执行操作。每次修改操作完毕后，都会将资源版本号加一。如果两个并发请求同时修改一个资源，则其中一个请求的修改会失败，因为当前的版本号与请求中的版本号不同。此时，客户端需要重新请求资源，并指定重新获取资源的版本号。
具体来说，客户端发送一个 PATCH 请求时，需要在请求头中指定当前的版本号，如下所示：
-- -------------------- ---- -------
----------------------------- -
------- --------
-------- -
--------------- -------------------
----------- ---
--
----- ----------------
--- --
------ ------
-------- -
--
--服务器需要验证当前资源的版本号与客户端指定的版本号是否一致，如果不一致，则返回 409（Conflict）错误码，提示客户端当前尝试修改的资源版本已过期，需要重新获取最新的版本号。
-- -------------------- ---- -------
--------------------------------- ----- ----- ---- -- -
----- -------- - ----- ------------------ ------ - --- ----------- - ---
-- ----------------- --- ----------------- -
----------------------
-------- ------------------
---
-------
-
-- ------------- --
----- -----------------
------ ------
-------- ---------------- - -
---
-------------------
---总结
本文首先介绍了 RESTful API 的并发请求问题，并详细探讨了多种解决方法。通过增加版本号、采用悲观锁和采用乐观锁三种方式，我们可以有效避免并发请求导致的资源状态不可预测问题。考虑具体业务场景和实现技术，我们可以选择最适合自己的解决方法，并对其进行进一步优化。希望本文能为前端开发者解决并发请求问题提供参考和指导帮助。
示例代码
资源接口定义：
-- -------------------- ---- -------
----- --------- - ---------------------
----- --------- - --- --------------------- ----------- ----------- - -------- -------- ---
----- -------- - ---------------------------- -
--- -
----- ------------------
----------- -----
-------------- ----
--
------ -
----- -----------------
---------- ----
--
-------- -
----- ------------------
------------- -
-
---
----------------
-------------- - ---------Express 路由部分：
-- -------------------- ---- -------
----- ------- - -------------------
----- ---------- - -----------------------
----- -------- - -----------------------------
----- --- - ----------
---------------------------
--------------------------------- ----- ----- ---- -- -
----- -------- - ----- ------------------ ------ - --- ----------- - ---
-- ----------------- --- ----------------- -
----------------------
-------- ------------------
---
-------
-
-- ------------- --
----- -----------------
------ ------
-------- ---------------- - -
---
-------------------
---
---------------- -- -- ------------------- ------- -- ---- --------来源：JavaScript中文网 ，转载请注明来源 https://www.javascriptcn.com/post/645fa2c1968c7c53b019f50c