我看到了一堆回答，说将用户123的所有内容放在资源“/user/123”是RESTful的。

罗伊·菲尔丁（Roy Fielding）创造了这个术语，他表示RESTAPI必须是超文本驱动的。特别是，“REST API不能定义固定的资源名称或层次结构”。

因此，如果您的“/user/123”路径在客户端上被硬编码，那么它就不是真正的RESTful。很好地使用HTTP，也许，也许不是。但不是RESTful。它必须来自超文本。

如果我不得不将关于REST的原始论文缩减为短短的3句话，我认为以下内容抓住了它的精髓：

通过URL请求资源。协议仅限于使用URL进行通信的内容。元数据作为名称-值对（发布数据和查询字符串参数）传递。

之后，很容易陷入关于适应、编码约定和最佳实践的争论。

有趣的是，本文中没有提到HTTPPOST、GET、DELETE或PUT操作。这一定是后来有人对“统一界面”的“最佳实践”的解释。

当涉及到web服务时，我们似乎需要一些方法来区分WSDL和基于SOAP的体系结构，这会给接口增加相当大的开销和不必要的复杂性。它们还需要额外的框架和开发人员工具才能实现。我不确定REST是否是区分常识接口和过度工程化接口（如WSDL和SOAP）的最佳术语。但我们需要一些东西。

REST定义了6个体系结构约束，使任何web服务都成为真正的RESTful API。

统一接口客户端-服务器无国籍的可缓存的分层系统按需编码（可选）

https://restfulapi.net/rest-architectural-constraints/

这就是它可能看起来的样子。

创建具有三个财产的用户：

POST /user
fname=John&lname=Doe&age=25

服务器响应：

200 OK
Location: /user/123

以后，您可以检索用户信息：

GET /user/123

服务器响应：

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

要修改记录（姓名和年龄将保持不变）：

PATCH /user/123
fname=Johnny

要更新记录（因此lname和age将为NULL）：

PUT /user/123
fname=Johnny

REST==HTTP类比是不正确的，除非你不强调它“必须”是HATEOAS驱动的。

罗伊自己在这里清除了它。

输入REST API时，除了初始URI（书签）和适用于预期受众的一组标准化媒体类型（即，预期任何可能使用该API的客户端都能理解）之外，不应有任何先验知识。从那时起，所有应用程序状态转换都必须由客户端选择服务器提供的选择来驱动，这些选择出现在接收的表示中，或者由用户对这些表示的操作来暗示。转换可以由客户端对媒体类型和资源通信机制的知识来确定（或限制），这两者都可以动态地改进（例如，按需编码）。

[这里的失败意味着带外信息正在驱动交互，而不是超文本。]

我会说，RESTful编程是关于创建遵循REST体系结构风格的系统（API）。

我发现M.Elkstein博士的这篇关于REST的精彩、简短且易于理解的教程，并引用了最能回答您问题的重要部分：

学习REST：教程

REST是一种用于设计网络应用程序的架构风格。其思想是，使用RPC或SOAP连接机器，使用简单的HTTP机器之间的呼叫。在许多方面，基于HTTP的万维网本身可以被视为基于REST的架构。RESTful应用程序使用HTTP请求来发布数据（创建和/或更新）、读取数据（例如进行查询）和删除数据。因此，REST对所有四个CRUD（创建/读取/更新/删除）操作使用HTTP。

我认为你不应该因为没有听到堆栈溢出之外的REST而感到愚蠢。。。，我也会遇到同样的情况！；另一个SO问题“为什么REST现在变得越来越大”的答案可能会缓解一些情绪。