REST：请求作为响应的子集

Question

我在 HTTP API 上遇到了许多 JSON，这些 API 被认为是 RESTful，但我不确定以下设计是否遵循 REST 原则 - 请求模型被用作响应模型的子集。

例如，POST /flight/inquiry 要求：

{ 
   "flight_no":"2384B",
   "departure_time":78163918839123,
   "arrival_time":78163918889382,
   ...
}

回应：

{
  "request" : 
     { 
       "flight_no":"2384B",
       "departure_time": 78163918839123,
       "arrival_time": 78163918889382,
       ...
     }
  "status" : "ON TIME"
  "last_updated" :  7816391884313,
  ...
}

如果我们按照Richardson Maturity Model来分析这个，我认为它不符合1级的条件，因为没有明确的Resource定义。如果我们在此处将“查询”称为资源，则响应不应具有查询结果，例如状态、last_updated 等。通常，它应以可以传递到第二个端点的查询 ID（如 123）进行响应@ 987654324@。 这种方法虽然更符合 REST 原则（如果我错了，请纠正我），开发人员倾向于避免它，因为它很容易在单个端点而不是两个端点中压缩相同的行为。我的问题是，在这种更容易走捷径的情况下，忽略 REST 原则会产生后果吗？

Answer 1

我认为你目前的理解是可疑的。

使用 POST 请求资源的表示不是 RESTful，因为我们有 GET，它更合适。

当信息对应于潜在资源时，使用 POST 进行信息检索不是 RESTful，因为这种用法会妨碍安全的可重用性和拥有 URI 的网络效应。 -- Fielding, 2008

更多惯用的查询看起来更像

GET /flights?flight_no=2384B

甚至

GET /flights?flight_no=2384B&departure_time=78163918839123&arrival_time=78163918889382

在这些情况下，没有人会惊讶于标识符中使用的相同“参数”在资源表示中也重复出现。

鉴于客户端为查询分配了 POST 语义，因此响应如下所示绝对没有问题：

200 OK
Content-Location: https://example.org/flights?flight_no=2384B&departure_time=78163918839123&arrival_time=78163918889382

在这种情况下，响应正文中出现参数也是完全正常的（就像客户端直接在该资源上使用 GET 一样）。

在这种更容易走捷径的情况下，忽略 REST 原则会产生后果吗？

如果你放宽REST architectural constraints，那么你就不能再指望相应的属性保持不变了。

特别是，当您开始用自己的定制语义替换统一接口时，您牺牲了原本可以提供帮助的通用组件的功能。