REST :请求作为响应的子集
我遇到过许多，它们应该是RESTful，但我不确定下面的设计是否遵循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,
...
}如果我们用Richardson成熟度模型来分析这一点，我认为它将不符合第1级，因为没有明确的资源定义。如果我们在这里调用‘inquiry_id’作为资源，响应不应该在查询(如status、inquiry_id等)上有结果。通常，它应该使用可以传递到第二个端点GET /flight/123/status的inquiry_id(类似于123)进行响应。尽管这种方法更符合REST原则(如果我错了，请告诉我)，开发人员倾向于回避它，因为在一个端点而不是两个端点上很容易挤压出相同的行为。我的问题是，在这种情况下，忽略REST原则有什么后果吗?在这种情况下，走捷径更容易吗？
回答 1
Stack Overflow用户
发布于 2020-02-09 05:44:06
我认为你目前的理解是值得怀疑的。
使用POST请求资源的表示不是RESTful，因为我们有GET，这更合适。
当信息与潜在资源相对应时，使用POST进行信息检索并不是RESTful，因为这种使用会阻碍安全的可重用性和具有URI的网络效果。-- 菲尔丁，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体系结构约束，那么您就不能再期望相应的属性保持。
特别是，当您开始用您自己定制的语义替换统一接口时，您牺牲了通用组件的功能，而这些功能本来可以帮助您。
https://stackoverflow.com/questions/60134254
复制
腾讯云开发者
