满足哪些条件的Web服务才可被称为完整的RESTful Web服务？

我太懂你这种被面试官追问的窘迫了！当初我第一次答这个问题时，也只说了“用HTTP方法返回JSON/XML”，结果被面试官笑着说“那只能叫HTTP接口，算不上RESTful”😂。要被称为完整的RESTful Web服务，得严格遵循Roy Fielding提出的REST架构约束，再加上一些实践中的规范，具体来说：

一、必须满足的REST架构约束 #

这些是REST的核心，缺一不可：

• 客户端-服务器分离：客户端和服务端职责明确，客户端负责UI和用户交互，服务端负责数据存储和业务逻辑，两者独立演化——比如前端换框架不用改后端接口，后端换数据库不用影响前端。
• 无状态通信：每个请求必须包含服务端处理它所需的全部信息，服务端不保存任何客户端会话状态。比如不用Session存用户登录状态，而是让客户端在请求头里带JWT Token，这样服务端可以轻松水平扩展，不用考虑会话同步问题。
• 可缓存性：响应必须通过HTTP头明确标记是否可缓存（比如Cache-Control、ETag），客户端可以缓存重复请求的结果，减少服务器压力和响应时间。比如GET /products的响应头加Cache-Control: max-age=3600，表示1小时内可以直接用缓存返回结果。
• 统一接口：这是REST最关键的特征，确保接口简洁且一致，又分为4个子约束：
  1. 资源识别：每个资源都有唯一的URI标识，比如用/users/123表示ID为123的用户，而不是/getUser?id=123这种RPC风格的接口。
  2. 通过资源表示操作资源：客户端拿到资源的表示（比如JSON、XML）后，就能通过这个表示来修改或删除资源。比如GET /users/123拿到用户数据，修改后用PUT提交回同一个URI完成更新。
  3. 自描述消息：每个请求和响应都包含足够的元数据让对方理解如何处理。比如请求头的Content-Type: application/json告诉服务端请求体是JSON格式，响应头的Accept: application/xml告诉服务端客户端期望XML格式的返回。
  4. HATEOAS（超媒体作为应用状态引擎）：响应中要包含超链接，引导客户端下一步可以执行的操作，不需要客户端硬编码URI。比如GET /users/123的响应可以是：

     {
       "id": 123,
       "name": "Alice",
       "email": "alice@example.com",
       "links": [
         {"rel": "orders", "href": "/users/123/orders"},
         {"rel": "update", "href": "/users/123"}
       ]
     }
     

     客户端看到orders链接就知道可以去查该用户的订单，不用提前知道/users/123/orders这个URI。
• 分层系统：服务端可以由多层组成（比如负载均衡层、缓存层、业务逻辑层、数据层），客户端只需要和最外层交互，不用关心内部架构。这样可以提高系统的扩展性、安全性和可维护性。

二、实践中的规范要求 #

除了架构约束，还有一些约定俗成的规范，也是面试官很看重的：

• 正确使用HTTP方法：
  • GET：用于获取资源，幂等（多次请求结果相同），不能修改资源状态。
  • POST：用于创建新资源，非幂等（多次请求会创建多个资源），比如提交表单创建用户。
  • PUT：用于更新整个资源，幂等，比如替换用户的所有信息。
  • PATCH：用于更新资源的部分字段，通常非幂等。
  • DELETE：用于删除资源，幂等。
• 合理使用HTTP状态码：
  • 200 OK：成功的GET、PUT、PATCH或DELETE请求。
  • 201 Created：POST创建资源成功，同时返回Location头指向新资源的URI。
  • 204 No Content：DELETE成功或PUT/PATCH没有返回内容时使用。
  • 400 Bad Request：请求格式错误（比如JSON语法错误）。
  • 401 Unauthorized：用户未认证。
  • 403 Forbidden：用户已认证但无权限访问资源。
  • 404 Not Found：请求的资源不存在。
  • 405 Method Not Allowed：使用了不支持的HTTP方法（比如给GET-only接口发POST）。
  • 500 Internal Server Error：服务端内部逻辑出错。

简单来说，你之前的回答只触及了REST的“皮毛”——用HTTP方法和数据格式，但REST的核心是架构约束和统一接口，只有满足这些，才能被称为完整的RESTful Web服务。

内容的提问来源于stack exchange，提问作者user6650906