本文是小编为大家收集整理的关于从另一个资源的POST请求中创建外键记录是RESTful吗？的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
所以我在我的API中有一些资源，除非首先对该特定资源进行帖子，否则无法创建这些FK记录(按设计).
我无法通过发布葡萄酒来创建一个国家，即使国家是外国钥匙.
帖子将进入/api/葡萄酒不是/api/country
换句话说，如果我将此有效载荷发送到葡萄酒资源:
{
id: 79,
name: "Bordeaux",
country: {
id: 76,
code: "FR",
name: "France"
},
year: "2005"
}
它将失败，除非该国家已经存在.我们无法从这篇文章中创建国家，因为我们发布到葡萄酒资源而不是国家.
这是通过设计，因为API中还有其他外部关键关系，消费者永远无法修改或创建.此外，让消费者从单个有效载荷创建多个资源似乎是它将打开介绍错字，重复记录和弄脏数据的可能性，尤其是API尺度和人们正在写入它并熟悉推送数据进入它.
如果我有一个endpoint，它反映了一个外键关系链
/api/planet/country/state/city/postal_code/
，我发出帖子:
/api/postal_code/
我不应该能够创建一个行星，国家，州或城市，如果存在，我应该只能引用这些资源的现有记录，然后最终创建一个新的邮政编码.
我的问题只是，这是什么标准的做法?哪种方法更常用.如果我要打开我的API来支持从单个端点创建每个外部密钥资源 - 似乎它似乎将首先删除使用外键关系的一些好处.
推荐答案
您的方式依赖.要创建葡萄酒排，您需要了解该葡萄酒的所有相关细节.
嵌套的路线很好，当您有一个用例时查看所有葡萄酒，与特定公司只有葡萄酒.
即:
GET /api/wine/ <- 会返回数据库中的所有葡萄酒 vs.
GET /api/countries/76/wine <- 会返回法国的所有葡萄酒.
否则，这两种方式都在依赖于该路线描述资源，并且更新其保持不变的模式.
其他推荐答案
在调用新的创建子资源API时创建父资源并不依赖.如果父资源必须存在以创建子资源，则最好的方法是遵循分层API结构并抛出异常如果找不到引用的父资源.
Hierarchical API structure : /api/countries/$country_id/wines - POST
如果您遵循此结构，API消费者将知道客户端API必须正常工作.
另一方面，如果您觉得API变长度，则可以在父资源(国家/地区)不存在时抛出异常.问题描述
So I have some resources in my API with foreign key relationships and these fk records (by design) cannot be created unless a POST is made to that specific resource first.
I cannot create a Country by POSTing to Wine even though Country is a foreign key.
the POST is going to /api/wine not /api/country
In other words, if I send this payload to Wine resource:
{
id: 79,
name: "Bordeaux",
country: {
id: 76,
code: "FR",
name: "France"
},
year: "2005"
}
It will fail unless that country already exists. We cannot create the country from this POST because we are POSTing to the Wine resource and not Country.
This was by design because there are other foreign key relationships in the API that the consumer should never be able to modify or create. Furthermore, letting the consumer create multiple resources from a single payload seems like it would open up the possibility of introducing typo's, duplicate records, and dirtying the data, especially as the API scales and people are writing scripts around it and getting familiar with pushing data into it.
If I have a GET endpoint that reflects a chain of foreign key relationships
/api/planet/country/state/city/postal_code/
and I make a POST to:
/api/postal_code/
I should not be able to create a planet, country, state or city, I should only be able to refer to existing records for these resources if they exist and then finally create a new postal code.
My question is simply, what is the standard practice for this? Which methodology is more commonly used. If I were to open up my API to support creating every foreign key resource from a single endpoint - it seems like it would remove some of the benefits of using foreign key relationships in the first place.
推荐答案
The way you have it is RESTful. To create a wine row, you do need to know all of the relevant details for that wine.
Nested routes are good when you have a use case to see all wine, versus wine just from a specific company.
Namely:
GET /api/wine/ <-- Would return all wine in the database vs.
GET /api/countries/76/wine <-- Would return all wine just for France.
Otherwise, both ways are RESTful in that the route describes the resource, and the patterns for updating it remain the same.
其他推荐答案
Creating a parent resource when a new create child-resource api is called is not RESTful. If the parent-resource has to exist in order to create a child resource, the best way is to follow the hierarchical api structure and throw exceptions if the referred parent resource is not found.
Hierarchical API structure : /api/countries/$country_id/wines - POST
If you follow this structure the api consumers will know that these parent resources must exist for the client apis to work properly.
On the other hand, if you feel that the api becomes lengthier, you can just throw exceptions when the parent resource(country) does not exist.
更多相关问答
联系站长