所以我的API中有一些资源与外键关系，除非首先对该特定资源进行POST，否则无法创建这些fk记录（按设计）。
即使Country是外键，我也无法通过POST到Wine创建国家/地区。
POST将转至/ api / wine not / api / country
换句话说，如果我将此有效负载发送到Wine资源：
{
id: 79,
name: "Bordeaux",
country: {
id: 76,
code: "FR",
name: "France"
},
year: "2005"
}
除非该国家已存在，否则将失败。我们无法从此POST创建国家/地区，因为我们正在发布到Wine资源而不是国家。
这是设计原因，因为API中存在其他外键关系，消费者永远无法修改或创建。此外，让消费者从单个有效负载创建多个资源似乎会开启引入拼写错误，重复记录和弄脏数据的可能性，特别是当API扩展并且人们围绕它编写脚本并获得熟悉将数据推入其中。
如果我有一个反映外键关系链的GET端点
/api/planet/country/state/city/postal_code/
我发布了一个帖子：
/api/postal_code/
我不应该创建一个行星，国家，州或城市，我应该只能参考这些资源的现有记录（如果存在），然后最终创建一个新的邮政编码。
我的问题很简单，这是什么标准做法？哪种方法更常用。如果我打开我的API以支持从单个端点创建每个外键资源 - 似乎它将首先消除使用外键关系的一些好处。
答案 0 :(得分：0)
你拥有它的方式是RESTful。要创建葡萄酒行，您需要知道该葡萄酒的所有相关细节。
当您有一个用例来查看所有葡萄酒时，嵌套路线是好的，而不是来自特定公司的葡萄酒。
即：
GET /api/wine/＆lt; - 将返回数据库中的所有葡萄酒
VS
GET /api/countries/76/wine＆lt; - 将为法国归还所有葡萄酒。
否则，两种方式都是RESTful，因为路由描述了资源，并且更新它的模式保持不变。
答案 1 :(得分：0)
在调用新的create-child-resource api时创建父资源不是RESTful。如果父资源必须存在才能创建子资源，最好的方法是遵循分层api结构，并在未找到引用的父资源时抛出异常。
Hierarchical API structure :
/api/countries/$country_id/wines - POST
如果您遵循此结构，api消费者将知道必须存在这些父资源才能使客户端apis正常工作。
另一方面，如果您认为api变得更长，那么当父资源（国家/地区）不存在时，您可以抛出异常。