RESTful API设计疑问：请求作为响应子集是否合规？捷径有何后果？

首先，你的判断完全正确——那种直接在POST /flight/inquiry响应里嵌套请求内容+查询结果的设计，确实达不到Richardson成熟度模型的Level 1。Level 1的核心是识别并暴露独立的资源，而当前设计把"查询动作"和"查询结果"混在了一个接口里，没有将航班查询请求（Inquiry）作为一个独立的资源来处理。理想的RESTful设计应该是：通过POST创建Inquiry资源，返回inquiry_id，再通过GET /flight/inquiry/{inquiry_id}来获取包含status、last_updated的查询结果。

接下来聊聊图省事用单接口的几个关键后果：

• 丧失HTTP缓存能力：REST的核心优势之一是利用HTTP缓存减少重复请求，但POST请求默认是不可缓存的（除非手动配置复杂的缓存策略）。如果把查询结果直接放在POST响应里，客户端没法利用浏览器、CDN或网关的缓存机制，每次查询都得重新发起请求，徒增服务器负载和网络开销。
• 资源状态无法追踪与复用：没有独立的inquiry_id，就没法对这个查询请求的状态做后续操作——比如用户想刷新最新的航班状态、或者分享这个查询结果给他人，都得重新提交完整的请求参数。而有了inquiry_id，只需要调用对应的GET接口即可，参数更简洁，也能保留查询的历史状态。
• 混淆HTTP方法语义：POST方法的标准语义是"创建资源"，而非"执行查询并返回结果"。虽然技术上能跑通，但这种设计模糊了动作和资源的边界，让API的语义变得不直观，其他开发者接手时需要额外理解接口的特殊逻辑，大幅增加维护成本。
• 扩展性严重受限：如果后续需要给航班查询增加新功能——比如支持查询进度、取消未完成的查询、批量获取多个查询结果，单接口的设计会变得越来越臃肿，最终沦为难以维护的"大泥球"。而基于资源的设计只需要扩展对应的资源端点（比如GET /flight/inquiry做批量查询，DELETE /flight/inquiry/{id}取消查询），结构始终清晰。
• 难以实现幂等性：POST请求默认是非幂等的，重复提交可能会创建多个查询资源（如果后端没做去重逻辑）。但如果用"POST创建资源+GET查询结果"的模式，POST只负责创建一次Inquiry，后续重复调用GET是幂等的，不会产生副作用，更符合HTTP规范。

当然，也不是说这种单接口设计完全不能用——如果是非常简单的一次性查询，且确定永远不会有后续扩展需求，短期内在开发效率上确实有优势。但从长期维护和API的健壮性来看，遵循REST原则的设计会更靠谱。

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