咱们做开发的，十有八九都写过或者调过所谓的“RESTful”接口。但我敢打赌，很多人见过的接口文档里，满屏都是HTTP 200 OK，然后 JSON Body 里藏着一个code: 500和msg: "系统内部错误"。这场景熟不熟悉？前端兄弟一边骂一边写if (res.code !== 200)的判断逻辑，后端兄弟觉得“我把错误信息都给你了，还要啥自行车？”。其实，这种“挂羊头卖狗肉”的做法，在架构设计上是典型的“语义丢失”。今天咱们就脱下“CRUD 熟练工”的外衣，站在系统架构师的视角，聊聊为啥设计一个正经的 RESTful API 这么重要，以及在软考高级架构师的考试和论文里，咱们该怎么体现这种专业性。一、 HTTP 状态码不是摆设，是“通用语言”很多朋友觉得，只要 URL 长得像/users/123就算 RESTful 了。其实不然，REST（表述性状态转移）的核心精髓之一，在于充分利用 HTTP 协议本身定义的语义。200 OK 一把梭的坏处当你把所有返回都包装成 200 OK 时，你实际上是废掉了 HTTP 协议的一半功能：