为什么很多后端写接口都不按照restful规范？
你这个问题触及到很多后端开发者的痛点，也暴露了现实世界与理想规范之间的差距。其实，说“很多”后端不完全遵循RESTful规范，这确实是一个普遍现象。要深入理解原因，咱们得一层层剥开来看。
首先，我们要明确什么是RESTful。它不是一个标准，而是一种架构风格，强调的是无状态、客户端服务器、统一接口、可缓存、分层系统、按需代码（可选）这几个核心原则。而“统一接口”里又包含了几点关键：
资源标识： 用URL来唯一标识资源（例如 `/users/123`）。
资源操作： 通过HTTP动词（GET, POST, PUT, DELETE, PATCH等）来对资源进行操作。
表示形式： 客户端和服务器之间通过资源的不同表示形式（如JSON, XML）进行数据交换。
超媒体作为应用状态的引擎 (HATEOAS)： 响应中包含链接，指导客户端如何进行下一步操作。
绝大多数开发者理解并遵循前三点（URL、HTTP动词、数据格式），但HATEOAS往往是被忽略的。
那么，为什么会有这么多“不那么RESTful”的接口呢？这背后原因挺复杂的，可以从技术、团队、业务、历史等多个维度来分析。
1. 历史包袱与技术演进
早期Web的“非RESTful”遗留： 在RESTful概念普及之前，很多Web应用就已经存在了。那时候，大家更多地是直接操作URL，比如 `getUser.php?id=123`，或者 `updateUser.do?id=123&name=test`。这些模式根深蒂固，很多老项目在重构时，为了快速上线或避免大规模改动，会选择保留原有风格，只是在表面上添加了一些RESTful的元素。
RPC的思维惯性： 在RESTful出现之前，远程过程调用（RPC）是分布式系统的主流。RPC的风格更像是直接调用函数，比如 `UserService.getUser(123)`。这种思维模式使得开发者在设计API时，也倾向于将“动作”放在URL中，例如 `/users/getUser/123` 或者 `/users/update`，而不是用HTTP动词来表达操作。即使后来采用了HTTP协议，这种“动词+资源”的模式也很难一下子甩掉。
技术选型和框架的影响： 某些框架或技术栈在设计之初，可能并没有将RESTful作为首要考虑，或者提供了方便的方式来实现非RESTful的路由。例如，早期的一些PHP框架，MVC结构中的ControllerAction模式，很容易导向 `/controller/action/params` 这样的URL，与RESTful的资源导向有所不同。
2. 理解偏差与实践难度
对RESTful的片面理解： 很多开发者可能只学到了RESTful的皮毛，比如URL包含名词，GET对应查询，POST对应创建。但对RESTful更深层次的原则，尤其是“统一接口”的精髓，如HTTP动词的恰当使用、状态码的意义、缓存机制的利用，甚至HATEOAS，理解并不透彻，或者觉得过于复杂而选择性忽略。
HATEOAS的“鸡肋”感： HATEOAS（超媒体作为应用状态的引擎）是RESTful架构风格中一个非常重要的原则，它使得API可以自描述，客户端无需预知所有可能的URL，只需根据响应中的链接进行导航。然而，在实际的Web开发中，特别是在前后端分离不彻底，或者对API的可发现性要求不那么高的场景下，HATEOAS的实现成本高，且带来的收益并不总是那么直接和明显。很多团队觉得“费力不讨好”，于是就放弃了。
HTTP动词的误用或回避： 有时候，开发者会因为各种原因误用HTTP动词。比如，用GET去修改数据（虽然在技术上可能实现，但违背了GET的幂等性原则），或者所有操作都用POST来完成。这可能源于对HTTP协议理解的不足，或者为了简化实现。
资源粒度的定义模糊： RESTful强调对“资源”进行操作。但什么是资源？如何划分资源？这个边界在实际开发中往往是模糊的。有时候，开发者会将一个复杂的操作分解成多个资源，或者将多个操作打包进一个“动作”，导致URL和HTTP动词的组合不够清晰。
3. 业务需求与项目实际
快速迭代和上线压力： 在很多快速发展的项目中，产品经理和业务方要求快速响应市场变化，迭代新功能。在这种情况下，追求完美、遵循所有RESTful细节可能不是首要任务。开发者为了尽快交付，会选择更直接、更易于实现的方案，即使这意味着牺牲一部分API设计的优雅性。
特定业务场景的适配： 有些业务场景可能天然就不适合完全套用RESTful的模型。例如，一些非常复杂的、状态流转非常明确的业务流程，用纯粹的CRUD（增删改查）来表示可能会显得非常冗余和不直观。在这种情况下，开发者可能会选择更符合业务逻辑的、带有动作描述的API设计。
前后端耦合度的问题： 虽然RESTful提倡前后端分离，但现实中，很多项目的前后端耦合度还是比较高的。后端开发者可能更了解自己实现的功能，也更容易直接暴露操作接口。如果前端有明确的需求，后端直接实现给前端用，不那么“RESTful”可能反而更高效。
第三方服务集成： 如果你的应用需要集成很多第三方服务，而这些第三方服务的API设计风格各异，有时候为了保持一致性，你的API也可能需要做出妥协，采纳一些非RESTful的模式。
4. 团队习惯与沟通成本
团队成员的技术背景和习惯： 团队成员的技术背景和过往项目经验会很大程度上影响API的设计风格。如果团队成员普遍习惯于某种非RESTful的设计模式，或者对RESTful规范的理解不一致，那么在没有强制规范的情况下，就容易出现各种不同的设计风格。
沟通与规范的成本： 建立并强制执行一套严格的API设计规范需要投入时间和精力。需要开会讨论、编写文档、进行Code Review。如果团队规模不大，或者项目周期紧张，大家可能更倾向于“先做起来再说”，而不是花费大量时间在规范的制定和执行上。
维护成本的考量： 有时候，遵循RESTful规范可能会导致URL变得非常冗长，或者需要更多的API端点来覆盖所有操作。开发者可能会权衡“易于理解的URL”和“严格的RESTful”之间的关系，有时会选择稍微简化一些的URL结构，以降低理解和维护成本。
总结来说
不完全遵循RESTful规范并非“懒惰”或“无知”，而是在理想架构风格、技术实践、业务需求、团队习惯以及历史演进等多重因素作用下的权衡结果。
早期历史遗留和RPC思维惯性是起点。
对RESTful原则（特别是HATEOAS）理解的片面性或实践难度是技术上的挑战。
快速迭代、特定业务场景和前后端耦合是业务上的现实考量。
团队成员习惯、沟通成本和维护效率则是团队和项目管理层面的因素。
很多时候，开发者们遵循的是“RESTfulish”，即在RESTful思想的指导下，但根据实际情况进行一定的调整和简化，尤其是对HATEOAS等比较“重”的原则有所取舍。这并不意味着API设计得不好，而是为了在现实中找到一个更平衡、更高效的解决方案。
当然，这并不鼓励大家完全放弃RESTful原则。在团队有能力、项目允许的情况下，遵循RESTful规范仍然是构建可维护、可扩展、易于理解的API的最佳实践之一。关键在于理解这些原则的目的，并根据实际情况做出明智的权衡。
首先，我们要明确什么是RESTful。它不是一个标准，而是一种架构风格，强调的是无状态、客户端服务器、统一接口、可缓存、分层系统、按需代码（可选）这几个核心原则。而“统一接口”里又包含了几点关键：
资源标识： 用URL来唯一标识资源（例如 `/users/123`）。
资源操作： 通过HTTP动词（GET, POST, PUT, DELETE, PATCH等）来对资源进行操作。
表示形式： 客户端和服务器之间通过资源的不同表示形式（如JSON, XML）进行数据交换。
超媒体作为应用状态的引擎 (HATEOAS)： 响应中包含链接，指导客户端如何进行下一步操作。
绝大多数开发者理解并遵循前三点（URL、HTTP动词、数据格式），但HATEOAS往往是被忽略的。
那么，为什么会有这么多“不那么RESTful”的接口呢？这背后原因挺复杂的，可以从技术、团队、业务、历史等多个维度来分析。
1. 历史包袱与技术演进
早期Web的“非RESTful”遗留： 在RESTful概念普及之前，很多Web应用就已经存在了。那时候，大家更多地是直接操作URL，比如 `getUser.php?id=123`，或者 `updateUser.do?id=123&name=test`。这些模式根深蒂固，很多老项目在重构时，为了快速上线或避免大规模改动，会选择保留原有风格，只是在表面上添加了一些RESTful的元素。
RPC的思维惯性： 在RESTful出现之前，远程过程调用（RPC）是分布式系统的主流。RPC的风格更像是直接调用函数，比如 `UserService.getUser(123)`。这种思维模式使得开发者在设计API时，也倾向于将“动作”放在URL中，例如 `/users/getUser/123` 或者 `/users/update`，而不是用HTTP动词来表达操作。即使后来采用了HTTP协议，这种“动词+资源”的模式也很难一下子甩掉。
技术选型和框架的影响： 某些框架或技术栈在设计之初，可能并没有将RESTful作为首要考虑，或者提供了方便的方式来实现非RESTful的路由。例如，早期的一些PHP框架，MVC结构中的ControllerAction模式，很容易导向 `/controller/action/params` 这样的URL，与RESTful的资源导向有所不同。
2. 理解偏差与实践难度
对RESTful的片面理解： 很多开发者可能只学到了RESTful的皮毛，比如URL包含名词，GET对应查询，POST对应创建。但对RESTful更深层次的原则，尤其是“统一接口”的精髓，如HTTP动词的恰当使用、状态码的意义、缓存机制的利用，甚至HATEOAS，理解并不透彻，或者觉得过于复杂而选择性忽略。
HATEOAS的“鸡肋”感： HATEOAS（超媒体作为应用状态的引擎）是RESTful架构风格中一个非常重要的原则，它使得API可以自描述，客户端无需预知所有可能的URL，只需根据响应中的链接进行导航。然而，在实际的Web开发中，特别是在前后端分离不彻底，或者对API的可发现性要求不那么高的场景下，HATEOAS的实现成本高，且带来的收益并不总是那么直接和明显。很多团队觉得“费力不讨好”，于是就放弃了。
HTTP动词的误用或回避： 有时候，开发者会因为各种原因误用HTTP动词。比如，用GET去修改数据（虽然在技术上可能实现，但违背了GET的幂等性原则），或者所有操作都用POST来完成。这可能源于对HTTP协议理解的不足，或者为了简化实现。
资源粒度的定义模糊： RESTful强调对“资源”进行操作。但什么是资源？如何划分资源？这个边界在实际开发中往往是模糊的。有时候，开发者会将一个复杂的操作分解成多个资源，或者将多个操作打包进一个“动作”，导致URL和HTTP动词的组合不够清晰。
3. 业务需求与项目实际
快速迭代和上线压力： 在很多快速发展的项目中，产品经理和业务方要求快速响应市场变化，迭代新功能。在这种情况下，追求完美、遵循所有RESTful细节可能不是首要任务。开发者为了尽快交付，会选择更直接、更易于实现的方案，即使这意味着牺牲一部分API设计的优雅性。
特定业务场景的适配： 有些业务场景可能天然就不适合完全套用RESTful的模型。例如，一些非常复杂的、状态流转非常明确的业务流程，用纯粹的CRUD（增删改查）来表示可能会显得非常冗余和不直观。在这种情况下，开发者可能会选择更符合业务逻辑的、带有动作描述的API设计。
前后端耦合度的问题： 虽然RESTful提倡前后端分离，但现实中，很多项目的前后端耦合度还是比较高的。后端开发者可能更了解自己实现的功能，也更容易直接暴露操作接口。如果前端有明确的需求，后端直接实现给前端用，不那么“RESTful”可能反而更高效。
第三方服务集成： 如果你的应用需要集成很多第三方服务，而这些第三方服务的API设计风格各异，有时候为了保持一致性，你的API也可能需要做出妥协，采纳一些非RESTful的模式。
4. 团队习惯与沟通成本
团队成员的技术背景和习惯： 团队成员的技术背景和过往项目经验会很大程度上影响API的设计风格。如果团队成员普遍习惯于某种非RESTful的设计模式，或者对RESTful规范的理解不一致，那么在没有强制规范的情况下，就容易出现各种不同的设计风格。
沟通与规范的成本： 建立并强制执行一套严格的API设计规范需要投入时间和精力。需要开会讨论、编写文档、进行Code Review。如果团队规模不大，或者项目周期紧张，大家可能更倾向于“先做起来再说”，而不是花费大量时间在规范的制定和执行上。
维护成本的考量： 有时候，遵循RESTful规范可能会导致URL变得非常冗长，或者需要更多的API端点来覆盖所有操作。开发者可能会权衡“易于理解的URL”和“严格的RESTful”之间的关系，有时会选择稍微简化一些的URL结构，以降低理解和维护成本。
总结来说
不完全遵循RESTful规范并非“懒惰”或“无知”，而是在理想架构风格、技术实践、业务需求、团队习惯以及历史演进等多重因素作用下的权衡结果。
早期历史遗留和RPC思维惯性是起点。
对RESTful原则（特别是HATEOAS）理解的片面性或实践难度是技术上的挑战。
快速迭代、特定业务场景和前后端耦合是业务上的现实考量。
团队成员习惯、沟通成本和维护效率则是团队和项目管理层面的因素。
很多时候，开发者们遵循的是“RESTfulish”，即在RESTful思想的指导下，但根据实际情况进行一定的调整和简化，尤其是对HATEOAS等比较“重”的原则有所取舍。这并不意味着API设计得不好，而是为了在现实中找到一个更平衡、更高效的解决方案。
当然，这并不鼓励大家完全放弃RESTful原则。在团队有能力、项目允许的情况下，遵循RESTful规范仍然是构建可维护、可扩展、易于理解的API的最佳实践之一。关键在于理解这些原则的目的，并根据实际情况做出明智的权衡。
网友意见
重复一下观点
restful 很有种当年 MVC 的感觉，你知道他很流行，很火，似乎是必备知识（当年面试必考）。但是你实际使用他总觉得有明显的问题，但是你自己又不够自信觉得是自己理解有问题或者使用上没有掌握到精髓。
实际上他就是有问题，一个技术规范如果非常违反直觉并且实际生产中要为了这个规范妥协很多又没有很大的好处，他就是有问题的。
这类工程上的“原教旨主义”的例子特别多：
- 比如就是 spring security ，这绝对是有问题的设计，太J2EE了。
- 还有就是hibernate 当年几乎就是行业标准的存在，思维方式和restful很像，出发点是好的，思路也是好的，但是最终的结果就是需要妥协的。
- 还有就是前端react先引入的思想，不可变数据，数据变化引发的状态转移，但是实际如果完全按照react的思想来做其实很麻烦，但是从思路到框架上又很迷人。
restful真是让我怀疑我的品味是太特殊, 还是这个世界是错的.
至成心境：（转）深入理解什么是RESTful API
上面这篇文章中有个例子
GET /zoos：列出所有动物园 POST /zoos：新建一个动物园 GET /zoos/ID：获取某个指定动物园的信息 PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息） PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息） DELETE /zoos/ID：删除某个动物园 GET /zoos/ID/animals：列出某个指定动物园的所有动物 DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物 对比下面这一个
list_zone：列出所有动物园 create_zone：新建一个动物园 get_zone_by_id：获取某个指定动物园的信息 update_zone：更新某个指定动物园的信息（提供该动物园的全部信息） update_zone：更新某个指定动物园的信息（提供该动物园的部分信息） delete_zone：删除某个动物园 get_animals_of_zone：列出某个指定动物园的所有动物 delete_animal：删除某个指定动物园的指定动物 那个更清晰, 更精确, 更易于理解不是显而易见?
我唯一能想到的restful的优势就是, restful可以带来的难以维护的代码让人不容易失业
restful is a piece of shit!
很多人还不服. restful的可读性和下面这个没有太大区别
汪 /zoos：列出所有动物园 汪汪汪汪汪 /zoos：新建一个动物园 汪 /zoos/ID：获取某个指定动物园的信息 汪汪汪 /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息） 汪汪汪汪 /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息） 汪汪 /zoos/ID：删除某个动物园 汪 /zoos/ID/animals：列出某个指定动物园的所有动物 汪汪 /zoos/ID/animals/ID：删除某个指定动物园的指定动物 类似的话题
-
你这个问题触及到很多后端开发者的痛点，也暴露了现实世界与理想规范之间的差距。其实，说“很多”后端不完全遵循RESTful规范，这确实是一个普遍现象。要深入理解原因，咱们得一层层剥开来看。首先，我们要明确什么是RESTful。它不是一个标准，而是一种架构风格，强调的是无状态、客户端服务器、统一接口、可............. -
你这个问题问得很有意思，触及了我们对计算机系统理解的一个核心视角。我们习惯了在很多领域听到“前端”和“后端”的说法，比如Web开发、软件架构，甚至是数据库管理。但说到操作系统，我们似乎很少用“前后端”来描述它的构成。这背后其实有非常重要的原因，跟操作系统的本质、它所扮演的角色以及它的发展历史都有关。.............
-
.......
-
这个问题很有意思，也触及到不少人对海峡两岸语言状况的观察。与其说60、70年代的台湾人普通话比大陆人还标准，不如说他们在特定历史背景下，接触到的普通话更加“纯粹”和“统一”。这里面其实涉及几个关键因素，我们不妨细细道来：1. 历史背景的差异：国语推行与语言演变 台湾：国民党迁台后的“国语”政策 .............
-
70后对当下手机和游戏画质进步“不感兴趣”，这个说法可能有点绝对，但确实，相对于年轻一代，不少70后在这个领域的表现会显得更为“淡定”或者说“不那么狂热”。这背后其实是多种因素交织的结果，咱们一个一个掰扯开来聊。首先，得说说“时代背景”和“成长经历”。70后这一代，是伴随着改革开放成长起来的。他们年.............
-
“神童”长大后不如预期，这是一个非常普遍且令人深思的现象。这其中涉及到的原因非常复杂，可以从多个层面来分析，包括个体生理和心理发展、教育环境、社会压力以及人生选择等等。下面我将尝试详细地阐述这些方面：一、 生理与心理发展的差异： 大脑发展的不均衡： “神童”可能在某个特定年龄段，其大脑的某些区域.............
-
很多留学生回国后感到不快乐，这其实是一个挺普遍的现象，背后原因也挺复杂，不能简单归咎于某一点。咱们掰开了揉碎了聊聊，看看这背后到底有哪些隐情。一、 期望与现实的落差感这一点可能是最直接的，也是最普遍的。 镀金回国的滤镜碎裂： 在国外待了几年，很多留学生回国时心里都带着一种“镀金”的光环，觉得自己.............
-
大学毕业后，许多人感觉对二次元和Galgame的热情不如从前，这种现象其实相当普遍，背后涉及的因素也很多元，与其说是“没感觉了”，不如说是“感觉变了”，或者说，这份热情在更广阔的人生舞台上，被其他东西所稀释、置换和重塑了。首先，人生阶段的转变是最大的驱动力。 大学时期，尤其是课业相对轻松、生活重心相.............
-
很多大学生毕业后感叹大学所学知识“无用”，这可不是一句简单的抱怨，背后往往是多重原因交织的结果。就像一颗种子，如果在贫瘠的土壤里生长，即便它本身具备了发芽的潜力，最终也未必能长成参天大树。我们不妨从几个层面来剖析一下：一、 课程设置与现实脱节：理论的象牙塔与实践的土壤这是最直接也最普遍的感受。大学的.............
-
工作后不给父母钱，还能理直气壮，这背后其实挺复杂的，不能简单地用“孝顺”或者“不孝顺”来一概而论。我尝试从几个方面来聊聊，希望能把这个现象讲得细致一些。首先，咱们得承认，现在这个时代和过去太不一样了。1. 时代变迁和观念更新： 养育成本的“对等”： 很多父母年轻的时候，孩子都是“扔给”老人带，或.............
-
在我看来，这个问题挺有意思的，也很现实。为什么很多年轻人，一旦在生活中遇到不顺，就习惯性地把责任推到“社会”身上？这背后其实有不少错综复杂的原因，不能一概而论，得掰开了揉碎了说。首先，我们得承认，社会环境确实存在一些不公平和挑战。比如，教育资源分布不均，贫富差距拉大，不同家庭背景的孩子，起跑线就差了.............
-
这个问题其实很有趣，也常常被我们注意到。你有没有留意过，很多时候在路边、草丛里，甚至在你家地板上发现的已经死去的小家伙，它们的样子总是腹部朝上，四肢朝天？这并非是某种神秘的集体行为，而更多的是由一系列物理和生物学因素共同作用的结果。首先，让我们想想昆虫身体的构造。大多数昆虫的身体都有一个相对扁平的腹.............
-
.......
-
读完《三体》系列，特别是第三部《死神永生》，很多人会对程心这个角色感到愤怒、失望甚至憎恨，但对叶文洁的评价虽然复杂，却鲜少有那种纯粹的“骂”。这其中有着多方面的原因，涉及到人物塑造、故事走向、以及读者情感的投射。首先，我们要明白这两位女性角色的定位和行为动机的差异。叶文洁：绝望下的畸变，一个悲剧的开.............
-
福原爱担任日本青森大学客座副教授的消息，确实引发了不少关注。而如果仔细观察，你会发现近年来，退役运动员转型成为大学教职人员，特别是客座教授的例子并不少见。这背后并非偶然，而是多种因素共同作用的结果。首先，我们需要理解“客座教授”这个角色。客座教授通常不是全职的终身教授，而是学校邀请在特定领域具有突出.............
-
很多学霸毕业后选择不再成为“工作狂”，这一现象背后涉及多方面的心理、社会和现实因素。以下从多个角度详细分析这一现象的成因： 1. 学业与职场的“压力差异” 学业阶段的“目标明确”与职场的“模糊竞争” 学霸在学习阶段，目标清晰（如考取名校、拿高分），压力主要来自外部评价（如父母、老师、同龄人）。.............
-
高考结束，人生新篇章就此展开，对很多人来说，大学是梦想的起点。然而，在我们身边，总有那么一些身影，曾经在考场上奋笔疾书，如今却在大学校园里渐行渐远，仿佛失去了曾经的动力和目标。他们并非个例，这种“高考后堕落”的现象，背后隐藏着复杂的原因，值得我们深入剖析。首先，“目标达成就失去动力”是一个普遍的心理.............
-
很多父母在批评孩子后，并不希望他们哭泣，这背后有着复杂的原因，既有出于好意的考虑，也可能夹杂着一些不成熟的应对方式。要深入理解这一点，我们需要剖析父母的心态和他们所处的成长环境。首先，从父母的“好意”出发，他们不希望孩子哭，很大程度上是因为他们认为哭泣是“软弱”的表现。这是一种根深蒂固的社会观念，在.............
-
这个问题嘛，说起来就有点意思了。很多人觉得移民了的华人对中国没啥义务，但中国好像又得对人家负责，这背后其实牵扯到很多方面，挺复杂的。咱们一点一点捋捋。首先，咱们得明白，“义务”和“责任”这两个词语的指向性是不一样的。为什么很多人认为移民后的华人对中国“没有义务”？这主要是因为“义务”这东西，通常是建.............
-
夫妻结婚十几年后离婚的原因确实多种多样，而且往往不是单一因素造成的，而是多种问题长期累积的结果。以下我将从几个关键维度来详细阐述：一、 沟通的失效与误解的累积 缺乏有效沟通： 这是导致婚姻破裂最普遍也是最根本的原因之一。随着时间的推移，夫妻双方可能因为工作忙碌、生活压力、习惯养成等原因，沟通的机.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有