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