REST API中的PUT和POST。它们仅用于语义分离吗?

时间:2016-11-16 17:54:05

标签: rest post put

我被要求为前端团队创建一个端点RESTfull,它将向我发送有关用户表单的信息。

有很多场景但我只会解释1试图解决我的问题:

  1. 他们会向我发送一个包含大量用户数据的数组。例如userFirstName和userLastName。我需要检查数据库中是否存在用户。如果存在,请更新表单中发送的所有数据。如果用户不存在,请在表中创建它,然后在所有相关表中创建与新用户相关的信息。
  2. 因此,在这种情况下,我们在创建端点时可以有两种可能性:

    1. PUT if UPDATE data
    2. POST INSERT数据
    3. 我必须告诉他们在调用我的端点时他们应该使用什么动词,如果是PUT或POST。 我可以给他们POST并在此过程中进行一些更新,或者我可以给他们一个PUT并进行一些INSERT。

      基于RESTfull标准,不应该这样做。但除了这种最佳实践标准(语义)之外还有其他任何要约束的约束吗?

2 个答案:

答案 0 :(得分:0)

基本上,当您想要向服务器发送信息时,您应该使用HTTP方法 POST 。在我看来,您可以创建三个方法,POST方法来验证用户是否存在以及可以在验证后调用的INSERT和UPDATE方法。

答案 1 :(得分:0)

PUT在HTTP中具有非常特定的含义,即它表示资源表示的幂等替换。来自RFC 7231

  

PUT方法请求创建目标资源的状态,或者用请求消息有效负载中包含的表示定义的状态替换目标资源的状态。

如果您获取PUT消息的实体主体,从头构建一个新的资源表示,然后替换您之前的表示(思考键值存储),然后PUT是合适的。

另一方面,如果您使用您已有的表示合并请求正文中提供的表示,则PUT 不合适。

Fielding回复对It is ok to use POST的评论,建议

  

当更新操作是幂等的并且表示完成时,我们只使用PUT。

在HTTP中,POST是适用的方法,当其他方法都不合适时,这就是你在这里使用的方法。

但是......你没有理由不能拥有更多的资源(更多的是uris),包括为资源的每次编辑都有一个独特的uri。使用PUT创建一个新的资源,作为副作用也更新一些其他资源是一个完全可以接受的模式。这种新资源不一定非常耐用 - 只要副作用完成,你就可以让它过期。

它为您提供了PUT的幂等写语义,而不会违反HTTP强加的完整表示约束。