Question

所以我的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以支持从单个端点创建每个外键资源 - 似乎它将首先消除使用外键关系的一些好处。

Answer 1

你拥有它的方式是RESTful。要创建葡萄酒行，您需要知道该葡萄酒的所有相关细节。

当您有一个用例来查看所有葡萄酒时，嵌套路线是好的，而不是来自特定公司的葡萄酒。

即：

GET /api/wine/＆lt; - 将返回数据库中的所有葡萄酒 VS

GET /api/countries/76/wine＆lt; - 将为法国归还所有葡萄酒。

否则，两种方式都是RESTful，因为路由描述了资源，并且更新它的模式保持不变。

Answer 2

在调用新的create-child-resource api时创建父资源不是RESTful。如果父资源必须存在才能创建子资源，最好的方法是遵循分层api结构，并在未找到引用的父资源时抛出异常。

Hierarchical API structure :
/api/countries/$country_id/wines - POST

如果您遵循此结构，api消费者将知道必须存在这些父资源才能使客户端apis正常工作。

另一方面，如果您认为api变得更长，那么当父资源（国家/地区）不存在时，您可以抛出异常。