Json REST：请求作为响应的子集

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

例如，邮寄/航班/查询 请求：

{ 
   "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,
  ...
}

如果我们从资源的角度来分析，我认为它不符合1级标准，因为对资源没有明确的定义。如果我们将“查询”称为此处的资源，则响应不应具有查询结果，例如状态、上次更新等。通常，它应使用可传递到第二个端点的查询id（如123）进行响应

GET/flight/123/status

。

---

尽管这种方法更符合REST原则（如果我错了，请纠正我），但开发人员倾向于避免这种方法，因为很容易在一个端点而不是两个端点中压缩相同的行为。我的问题是，在这样的情况下，忽略REST原则是否会产生后果？在这种情况下，走捷径更简单？

我认为您目前的理解是可疑的

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

当信息与潜在资源相对应时，使用POST进行信息检索不是RESTful的，因为这种用法会阻止安全的可重用性和具有URI的网络效应

更惯用的查询看起来更像

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原则是否会产生后果

如果放松，则不能再期望相应的属性保持不变

---

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

解释得很好@VoiceofUnreason。在flight status示例中，输入计数是可管理的，可以作为查询参数包括在内。但是，如果涉及太多的输入，该怎么办呢。可以用10-15个查询参数来混乱URI吗？或者，对于这种情况，这是一种更好的设计吗？参数的数量不是一个重要的约束条件。如果URI本身足够长，以至于您开始遇到实现限制，那么您确实需要小心；看见