-
根据“REST意识形态”,PUT / POST / DELETE请求的响应主体应该是什么?
-
返回代码怎么样?
HTTP_OK
足够吗? -
这些公约的原因是什么?
我发现了一篇描述POST / PUT差异的好帖子:POST vs PUT但它仍然没有回答我的问题 .
根据“REST意识形态”,PUT / POST / DELETE请求的响应主体应该是什么?
返回代码怎么样? HTTP_OK
足够吗?
这些公约的原因是什么?
我发现了一篇描述POST / PUT差异的好帖子:POST vs PUT但它仍然没有回答我的问题 .
4 回答
原谅轻浮,但是如果您通过HTTP进行REST,则RFC7231会准确描述GET,PUT,POST和DELETE的预期行为 .
创建资源通常映射到POST,并且应该返回新资源的位置;例如,在Rails脚手架中,CREATE将重定向到SHOW以获取新创建的资源 . 同样的方法可能对更新(PUT)有意义,但这不是一个惯例;更新只需表明成功 . 删除可能只需要指示成功;如果你想重定向,返回资源的LIST可能是最有意义的 .
成功可以通过HTTP_OK表示,是的 .
我上面所说的唯一的硬性规则是CREATE应该返回新资源的位置 . 这对我来说似乎不费吹灰之力;完全可以理解客户端需要能够访问新项目 .
总的来说,这些惯例“就像你只是在提供网页一样” .
对于PUT,如果您之后立即执行GET,我将返回相同的视图;这将导致200(好吧,假设渲染成功当然) . 对于POST,我会重定向到创建的资源(假设您正在进行创建操作;如果没有,只返回结果);成功创建的代码是201,这实际上是不在300范围内的重定向的唯一HTTP代码 .
我从来没有对DELETE应该返回的内容感到高兴(我的代码当前生成了一个HTTP 204和一个空主体) .
通过RFC7231它没关系,可能是空的
我们如何在项目中实现基于json api标准的解决方案:
post / put:输出get中的对象属性(字段过滤器/关系应用相同)
delete:数据只包含null(表示缺少对象)
标准删除的状态:200