我正在设计一个REST API,其中Banner
资源与另外两个资源相关:Placeholder
和Page
。
虽然与Placeholder
的关系可以是null
,但Banner
必须与Page
相关联。业务规则定义页面始终是独立创建的。然后,对于新的Banner
资源,页面始终存在,页面的id可以作为参数传递。这同样适用于Placeholder
,但这可以null
。
所以,我决定也可以独立创建Banner
资源(而不是嵌套资源),如下所示:
POST https://api.example.com/banners
{
"name": "banner's name",
"page": "PAGE_ID",
"placeholder": "PLACEHOLDER_ID",
... other parameters
}
提供page
或placeholder
时,API应返回哪些错误代码?
我正在返回HTTP 404,但感觉很奇怪。我想到了409,但这看起来不像冲突。
PD:如果我将嵌套网址用作POST /pages/<page_id>/banners
,那么404对于不存在的page
是有意义的,但placeholder
仍有同样的问题。
答案 0 :(得分:0)
假设您要使用POST /banners
创建横幅资源,并且该横幅资源具有
page
属性,该值必须是现有的PAGE_ID placeholder
属性,该值必须是现有的PLACEHOLDER_ID 在帖子/横幅上返回404不是一个好主意
消费者可以从无提供所有无效属性。按照你的想法提供类似的东西:
page
无效,则会返回404 placeholder
无效,则会返回404 page
和placeholder
都无效,则必须返回404,表明这两个值都无效page
和/或placeholder
以及其他一些属性无效,哪种状态会返回? 404或400?它有点复杂且不一致,因此不适用于API的消费者。
400 Bad Request是一个更好的帖子/横幅解决方案
处理此用例的最佳方法是将提供的资源中的所有可能错误视为基本Client Error
,因此使用400 Bad Request
状态。响应正文将包含每个无效属性的每个错误的描述。
但是有一个更清晰的解决方案,包含POST / pages / page_id / placeholders / placeholder_id / banners
POST /pages/<page_id>/banners
几乎是一个好主意,你只需要进一步推动它。
似乎banner
进入placeholder
page
。如果确实如此,您可以POST /pages/<page_id>/placeholders/<placeholder_id>/banners
创建横幅。
page_id
无效,则返回404(表示未找到&#39;页面&#39;)page_id
有效,但placeholder_id
无效,则返回404(表示未找到地方持有人&#39;)page_id
和placeholder_id
有效,但横幅中的属性无效,则返回400错误请求(指示哪些值无效)