题 REST中的PUT与POST


根据HTTP / 1.1规范:

POST method用于请求源服务器接受请求中包含的实体作为由该标识所标识的资源的新下级 Request-URI 在里面 Request-Line

换一种说法, POST 习惯了 创建

PUT 方法请求将所包含的实体存储在提供的实体下 Request-URI。如果 Request-URI 指的是已经存在的资源,封闭的实体应该被认为是驻留在源服务器上的实体的修改版本。如果 Request-URI 没有指向现有资源,并且该URI能够被请求用户代理定义为新资源,源服务器可以使用该URI创建资源。

那是, PUT 习惯了 创建或更新

那么,应该使用哪一个来创建资源?或者需要支持两者?


4468
2018-03-10 14:25


起源


使用HTTPbis中的定义可能会有所帮助 - Roy将大量工作用于澄清它们。看到: tools.ietf.org/html/... - Mark Nottingham
只是为了将@MarkNottingham的评论带到最新版本,这里是 POST 和 放,如HTTPbis上所定义。 - Marius Butuc
在我看来,这种争论源于通过在CRUD操作方面描述HTTP方法来过度简化REST的常见做法。 - Stuporman
不幸的是,POST的第一个答案是错误的。检查我的答案,以便更好地解释差异: stackoverflow.com/a/18243587/2458234 - 7hi4g0
PUT和POST都是不安全的方法。但是,PUT是幂等的,而POST则不是。 - 更多信息请访问: restcookbook.com/HTTP%20Methods/put-vs-post/... - Dinesh Saini


答案:


总体: 

PUT和POST都可以用于创建。

你必须问“你在做什么动作?”区分你应该使用什么。我们假设您正在设计一个用于提问的API。如果您想使用POST,那么您可以将其添加到问题列表中。如果你想使用PUT,你会对特定问题这样做。

两者都可以使用,所以我应该在我的RESTful设计中使用哪一个:

您不需要同时支持PUT和POST。

使用哪种方法取决于你。但请记住使用正确的,具体取决于您在请求中引用的对象。

一些考虑:

  • 您是否明确指定了您创建的URL对象,还是让服务器决定?如果您为它们命名,那么使用PUT。如果您让服务器决定然后使用POST。
  • PUT是幂等的,所以如果你将对象PUT两次,它就没有效果。这是一个很好的属性,所以我会尽可能使用PUT。
  • 您可以使用具有相同对象URL的PUT更新或创建资源
  • 使用POST,您可以同时有2个请求进行URL修改,并且可以更新对象的不同部分。

一个例子:

我写了以下内容作为SO的另一个答案的一部分

POST:

用于修改和更新资源

POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/

请注意以下是一个错误:

POST /questions/<new_question> HTTP/1.1
Host: www.example.com/

如果尚未创建URL,则表示您   不应该使用POST来创建它   同时指定名称。这应该   导致“找不到资源”错误   因为 <new_question> 不存在   然而。你应该把它 <new_question>   首先是服务器上的资源。

你可以这样做   这个用POST创建资源:

POST /questions HTTP/1.1
Host: www.example.com/

请注意,在这种情况下资源   未指定name,新对象   URL路径将返回给您。

放: 

用于创建资源,或   覆盖它。当你指定   资源新网址。

对于新资源:

PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/

要覆盖现有资源:

PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/

3487
2018-03-10 14:29



我认为人们不能强调PUT是幂等的事实:如果网络拙劣并且客户端不确定他的请求是否通过,它可以发送它第二(或第100)时间,并且它由HTTP规范,这与发送一次具有完全相同的效果。 - Jörg W Mittag
@JörgWMittag:没必要。第二次可以返回409 Conflict或者其他东西,如果请求在此期间被修改(由某个其他用户或第一个请求本身通过)。 - Mitar
如果我没有弄错的话,我们应该强调的是PUT是 定义 是幂等的。您仍然必须以PUT行为正确的方式编写服务器,是吗?也许最好说“PUT使运输成为幂等,这可能会影响运输的行为,例如缓存。” - Ian Ni-Lewis
@JörgWMittagEdempotence标语?怎么样“发送和发送我的朋友,最终没有任何区别。” - James Beninger
将它们视为:PUT =插入或更新; POST =插入。所以当你做两个PUT时 - 你得到一个新记录,当你做两个POST时 - 你得到两个新记录。 - Eugen Konkov


你可以在网上找到断言

两者都不对。


更好的是在PUT和POST之间进行选择 幂等 行动。

 意味着放置一个资源 - 用不同的东西完全替换给定URL上的任何可用资源。根据定义,PUT是幂等的。你喜欢这么多次,结果是一样的。 x=5 是幂等的。无论以前是否存在,您都可以投入资源(例如,创建或更新)!

POST 更新资源,添加辅助资源或导致更改。 POST的方式不是幂等的 x++ 不是幂等的。


通过这个论点,PUT用于在您知道要创建的事物的URL时创建。当您知道要创建的事物类别的“工厂”或管理员的URL时,可以使用POST创建。

所以:

POST /expense-report

要么:

PUT  /expense-report/10929

1882
2018-04-22 14:55



我同意,无论在哪里有幂等性,它都应该胜过任何其他问题,因为错误会导致许多意想不到的错误。 - Josh
如果POST可以更新资源,那么它是如何不是幂等的?如果我使用PUT改变学生年龄并且这样做10倍,那么如果我做了一次,学生的年龄是相同的。 - Schneider
@Schneider,在这种情况下,你的服务器正在做出额外的努力以保证幂等性,但它并没有宣传它。如果用户尝试重新加载此类POST请求,浏览器仍会警告用户。 - Tobu
@Schneider POST可以创建一个辅助资源;因此你可以POST到收藏,比如 POST /费用报告 它会在您的服务器上创建与您发送的请求数量一样多的实体(费用报告),即使它们完全相似。可以将其视为在DB表(/ expense-reports)中使用自动递增的主键插入相同的行。数据保持不变,密钥(在这种情况下为URI)由服务器生成,并且对于每个其他插入(请求)都不同。所以,POST效果 能够 是幂等的,但也是 可能 不。因此,POST是 不 幂等。 - Snifff
假设我们有可能有两个属性的实体 - name 和 date。如果我们有一个现有的实体 name 和 date,但随后向它发出请求,仅指定一个 name,正确的行为 放 将是抹杀 date 实体,而 POST 可能只更新指定的属性,留下未指定的属性,就像它们在发出请求之前一样。这听起来是否正确/合理,还是使用不当 放 (我看到了参考文献 补丁,它似乎更合适,但还不存在)? - Jon z


  • POST 到URL 创建子资源 在... 服务器定义 URL。
  •  到URL 创建/替换资源 完整的 客户定义 URL。
  • 补丁 到URL 更新 部分 资源 在该客户端定义的URL。

PUT和POST的相关规范是 RFC2616§9.5ff。

POST创建子资源,所以POST到 /items 创造一种生活在世界之下的资源 /items 资源。 例如。 /items/1。两次发送相同的post数据包将创建两个资源。

 用于创建或替换资源 客户端已知的URL

因此:  只是CREATE的候选者,客户端在创建资源之前已经知道了url。例如。 /blogs/nigel/entry/when_to_use_post_vs_put 因为标题用作资源键

 如果已存在,则替换已知URL上的资源,因此两次发送相同的请求无效。换一种说法, 对PUT的调用是幂等的

RFC读起来像这样:

POST和PUT请求之间的根本区别体现在Request-URI的不同含义上。 POST请求中的URI标识将处理所包含实体的资源。该资源可能是数据接受过程,某些其他协议的网关或接受注释的单独实体。相反,PUT请求中的URI标识请求附带的实体 - 用户代理知道URI的用途,并且服务器不得尝试将请求应用于其他资源。如果服务器希望将请求应用于不同的URI,

注意: PUT主要用于更新资源(通过全部替换它们),但最近有使用PATCH更新现有资源的动作,因为PUT指定它替换整个资源。 RFC 5789。


563
2018-04-07 05:52



或者从围栏的另一侧:PUT如果客户端确定结果资源的地址,则在服务器执行POST时进行POST。 - DanMan
我认为应该编辑这个答案,以便更加清楚@DanMan以一种非常简单的方式指出的内容。我发现最有价值的是最后的注释,说明PUT应该仅用于替换整个资源。 - Hermes
PATCH至少在几年内不是一个现实的选择,但我同意这种意识形态。 - crush
我试图理解,但是如果客户端确实知道资源还不存在,那么使用PUT创建一些东西才会有意义,对吧?根据博客示例,假设您在几年内创建了数百个博客帖子,然后意外地选择了与两年前发布的帖子相同的标题。现在你已经离开并替换了那个不是故意的帖子。因此,使用PUT进行创建需要客户端跟踪所采取的措施和不采取的措施,并可能导致意外和意外的副作用,以及有两条完全不同的路线? - galaxyAbstractor
你是对的。将博客帖子放在与现有帖子相同的URL上会导致对现有帖子的更新(尽管您显然可以先使用GET进行检查)。这表明为什么仅使用标题作为URL是一个坏主意。然而,它可以在数据中存在自然键的任何地方工作......在我的经验中很少见。或者,如果您使用GUID - Nigel Thorne


概要:

创建:

可以通过以下方式使用PUT或POST执行:

创建 THE 新资源 newResourceId 作为标识符,在/ resources URI下,或 采集

PUT /resources/<newResourceId> HTTP/1.1 

POST

创建 一个 / resources URI下的新资源,或 采集。通常,服务器返回标识符。

POST /resources HTTP/1.1

更新:

能够 只要 以下列方式使用PUT执行:

使用更新资源 existingResourceId 作为标识符,在/ resources URI下,或 采集

PUT /resources/<existingResourceId> HTTP/1.1

说明:

在处理REST和URI时,你有 通用 在...上 剩下 和 具体 在...上 。该 仿制药 通常被称为 集合 而且更多 具体 可以调用项目 资源。注意一个 资源 可以包含一个 采集

例子:

< - generic - specific - >

URI: website.com/users/john
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource

URI:website.com/users/john/posts/23
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource
posts        - collection of posts from john
23           - post from john with identifier 23, also a resource

当你使用POST时,你是 总是 参考a 采集所以每当你说:

POST /users HTTP/1.1

你正在发布一个新用户 用户  采集

如果你继续尝试这样的事情:

POST /users/john HTTP/1.1

它会工作,但在语义上你说你想要添加资源 约翰  采集 在下面 用户  采集

一旦你使用PUT,你就是指的是 资源 或单个项目,可能在一个 采集。所以当你说:

PUT /users/john HTTP/1.1

你告诉服务器更新,或创建它是否不存在, 约翰  资源 在下面 用户  采集

规格:

让我重点介绍一下规范的一些重要部分:

POST

POST 方法用于请求原始服务器 接受 请求中包含的实体为  下属 请求行中的Request-URI标识的资源

因此,创造一个新的 资源 在...上 采集

 方法请求封闭的实体 存储 在提供的Request-URI下。如果Request-URI引用了 已经存在 资源,封闭的实体应该被视为一个 修改版 驻留在原始服务器上的那个。如果Request-URI有 没有指向现有的 资源,那个URI是  被定义为  资源 通过请求用户代理,源服务器可以 创建 具有该URI的资源。“

因此,基于存在而创建或更新 资源

参考:


164
2017-08-14 22:47



这篇文章有助于我理解POST将“某事”作为子项添加到给定集合(URI),而PUT明确定义给定URI位置的“某事”。 - kwah
这是最好的答案,在这里,我认为:没有一个“POST可以更新资源”废话。我喜欢你的陈述,“只能用PUT执行更新”。 - Thomas
不,PUT不用于更新或创建。这是为了更换。请注意,您可以使用某些内容替换任何内容以获得创建效果。 - thecoshman
@ 7hi4g0 PUT用于更新完全替换,换句话说,它替换。你不用任何东西取代任何东西,或用一些全新的东西取而代之。 PUT不是为了进行微小的改变(除非你让客户做出微小的改变并提供整个新版本,即使是保持不变的版本)。对于部分修改,PATCH是首选方法。 - thecoshman
@thecoshman你可以,但不太清楚创造也在那里。在这种情况下,最好是明确的。 - 7hi4g0


我想补充一下我的“务实”建议。当您知道可以检索要保存的对象的“id”时,请使用PUT。如果您需要返回数据库生成的ID以供将来查找或更新,则使用PUT将无法正常工作。

因此:要保存现有用户,或者客户端生成ID的用户,并且已验证该ID是唯一的:

PUT /user/12345 HTTP/1.1  <-- create the user providing the id 12345
Host: mydomain.com

GET /user/12345 HTTP/1.1  <-- return that user
Host: mydomain.com

否则,使用POST初始创建对象,并使用PUT更新对象:

POST /user HTTP/1.1   <--- create the user, server returns 12345
Host: mydomain.com

PUT /user/12345 HTTP/1.1  <--- update the user
Host: mydomain.com

155
2018-01-15 19:59



实际上,它应该是 POST /users。 (注意 /users 是复数。)这具有创建新用户并使其成为子资源的影响 /users 采集。 - DavidRR
@DavidRR公平,如何处理群体是另一场辩论。 GET /users 有道理,它按你的意愿读,但我会好的 GET /user/<id> 要么 POST /user (对于所述新用户的有效负载)因为它正确读取'让我用​​户5'是奇怪的,但'让我用户5'更自然。我可能仍然会在多元化的一面倒下:) - thecoshman


POST表示“创建新”,如“以下是创建用户的输入,为我创建”。

PUT表示“插入,替换,如果已经存在”,如“这是用户5的数据”。

您发布到example.com/users,因为您还不知道用户的URL,您希望服务器创建它。

您将pUT发送到example.com/users/id,因为您要替换/创建一个 具体 用户。

使用相同数据发布两次意味着创建两个具有不同ID的相同用户。使用相同数据进行两次输入会使用户创建第一次并在第二次将其更新为相同状态(无更改)。因为你在PUT之后无论你执行它多少次都会得到相同的状态,所以每次都被称为“同样有效” - 幂等。这对于自动重试请求很有用。当您按下浏览器上的后退按钮时,不再“您确定要重新发送”吗?

一般建议是在需要服务器控制资源的URL生成时使用POST。否则使用PUT。首选PUT over POST。


144
2017-10-23 14:27



邋iness可能导致通常教导你只需要两个动词:GET和POST。 GET获取,POST改变。甚至PUT和DELETE都是使用POST执行的。问25年后PUT真正意味着什么可能是我们一开始就认识错误的一个迹象。 REST的普及使人们回到基础,我们现在必须忘记过去的错误。 POST过度使用,现在通常教不正确。最好的部分:“使用相同的数据发布两次意味着创建两个相同的[资源]”。好点! - maxpolk
如何使用PUT通过ID创建记录,就像在您的示例中一样 user 5 如果它还不存在?不是吗? update, replace if already exists?或者其他的东西 - Luke
@Coulton:我的意思是我写的。如果PUT到/ users / 5并且#5尚不存在,则插入用户5。 - Alexander Torstling
@Coulton:而且 PUT 也可以用来 更换 一个人的价值 现有 整个资源。 - DavidRR
“更喜欢PUT over POST”......谨慎来证明这一点? - thecoshman


使用POST创建,并使用PUT进行更新。无论如何,Ruby on Rails就是这样做的。

PUT    /items/1      #=> update
POST   /items        #=> create

104
2018-03-10 14:28



POST /items 将新项添加到已定义的资源('item')。正如答案所说,它并没有“创造一个群体”。我不明白为什么这有12票。 - David J.
开箱即用,Rails不支持通过REST“创建组”。要“创建一个组”,我的意思是“创建一个资源”,你必须通过源代码来完成它。 - David J.
这是一个公平的指导方针,但过于简单化了。正如其他答案所提到的,任何一种方法都可以用于创建和更新。 - Brad Koch
我略微修改了同意答案。使用POST创建并PUT完全更新资源。对于部分更新,我们可以使用PUT或PATCH。让我们说我们想要更新组的状态。我们可以使用PUT / groups / 1 / status,状态是请求有效负载,或者PATCH / groups / 1,有关有效负载中的操作的详细信息 - java_geek
还应该明确指出 PUT /items/42 也适用于 创建 资源, 但仅当客户端具有命名资源的权限时。 (Rails是否允许客户端具有此命名权限?) - DavidRR


REST是一个 非常 高层次的概念。事实上,它甚至根本没有提到HTTP!

如果您对如何在HTTP中实现REST有任何疑问,您可以随时查看 原子发布协议(AtomPub) 规范。 AtomPub是一个使用HTTP编写RESTful webservices的标准,由许多HTTP和REST杰出人员开发,其中一些来自REST的发明者和HTTP本身(共同)发明者Roy Fielding的输入。

实际上,您甚至可以直接使用AtomPub。虽然它来自博客社区,但它绝不仅限于博客:它是一种通用协议,用于通过HTTP与任意资源的任意(嵌套)集合进行REST交互。如果您可以将应用程序表示为嵌套的资源集合,那么您可以使用AtomPub而不用担心是使用PUT还是POST,要返回的HTTP状态代码以及所有这些详细信息。

这就是AtomPub关于资源创建的说法(第9.2节):

要将成员添加到集合,客户端会将POST请求发送到集合的URI。


57
2018-03-10 15:27



允许PUT创建资源没有任何问题。请注意,这意味着客户端提供了URL。 - Julian Reschke
允许PUT创建资源有一些问题:客户端提供URL。这是服务器的工作! - Joshcodes
@Joshcodes创建客户端ID并不总是服务器的工作。我越来越多地看到让客户端生成某种UUID作为资源ID的设计。这种设计特别适合增加规模。 - Justin Ohms
@JustinOhms我同意你关于客户端生成的ID的观点(旁注:我自2008年以来设计的所有系统都要求客户端将ID作为UUID / Guid创建)。这并不意味着客户端应该指定URL。 - Joshcodes
@Joshcodes这是分离问题的问题。生成URL的位置实际上没什么影响。是的,服务器负责从正确的URL传递内容,但不限制服务器响应不正确的URL上的请求。在这种情况下,服务器的正确响应是308.然后,正确的客户端将在正确的URL上重试PUT。另一个例子是分布式系统,其中并非所有节点都知道客户端提供的所有资源。这里创建的PUT将完全有效,因为对于该服务器节点,资源不存在。 - Justin Ohms


是否使用PUT或POST在具有HTTP + REST API的服务器上创建资源的决定取决于谁拥有URL结构。 让客户端知道或参与定义URL结构是一种不必要的耦合,类似于SOA产生的不良耦合。逃避类型的耦合是REST如此受欢迎的原因。因此, 正确使用的方法是POST。 此规则有例外情况,当客户希望保留对其部署的资源的位置结构的控制时,就会出现这种情况。这很少见,可能意味着其他问题。

在这一点上,有些人会争辩说,如果 REST风格的URL的 如果使用,客户端确实知道资源的URL,因此PUT是可接受的。毕竟,这就是为什么规范,规范化,Ruby on Rails,Django URL很重要,看看Twitter API ......等等等等。那些人需要了解 没有Restful-URL这样的东西 然后 罗伊菲尔丁自己说

REST API不能定义固定资源名称或层次结构(an   客户端和服务器的明显耦合)。服务器必须具有自由   控制自己的命名空间。相反,允许服务器指示   客户端如何构造适当的URI,例如在HTML中完成   表单和URI模板,通过在媒体中定义这些指令   类型和链接关系。 [失败在这里意味着客户是   假设由于带外信息而产生资源结构,例如   特定于域的标准,它是面向数据的等价物   RPC的功能耦合]。

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

一个想法 REST风格的URL 实际上是违反REST,因为服务器负责URL结构,应该可以自由决定如何使用它来避免耦合。如果这让您感到困惑,请阅读有关API设计中自我发现的重要性。

使用POST创建资源需要考虑设计因素,因为POST不是幂等的。 这意味着多次重复POST并不能保证每次都有相同的行为。 这会让人们在不应该使用PUT时创建资源。 他们知道这是错误的(POST是为了CREATE),但无论如何他们都这样做,因为他们不知道如何解决这个问题。在以下情况中证明了这种担忧:

  1. 客户端将新资源POST到服务器。
  2. 服务器处理请求并发送响应。
  3. 客户端永远不会收到响应。
  4. 服务器不知道客户端没有收到响应。
  5. 客户端没有资源的URL(因此PUT不是一个选项)并重复POST。
  6. POST不是幂等的,服务器......

第6步是人们常常对做什么感到困惑。但是,没有理由创建解决此问题的方法。相反,可以按照指定使用HTTP RFC 2616 并且服务器回复:

10.4.10 409冲突

由于与当前的冲突,请求无法完成   资源状态。此代码仅在以下情况下允许   预计用户可能能够解决冲突   重新提交请求。响应机构应该包含足够的内容

用户识别冲突根源的信息。   理想情况下,响应实体将包含足够的信息   用户或用户代理来解决问题;然而,这可能不是   可能而且不是必需的。

冲突最有可能发生在响应PUT请求时。对于   如果正在使用版本控制并且实体是PUT   包括对资源的更改与资产的更改   在早期(第三方)请求中,服务器可能会使用409响应   表示无法完成请求。在这种情况下,   响应实体可能包含两者之间的差异列表   这两个版本采用响应Content-Type定义的格式。

回复状态代码为409 Conflict是正确的追索权,因为

  • 执行具有与系统中已有资源匹配的ID的数据POST是“与资源的当前状态冲突”。
  • 由于重要的部分是让客户了解服务器有资源并采取适当的措施。这是“用户可能能够解决冲突并重新提交请求的情况”。
  • 包含具有冲突ID的资源的URL以及资源的适当前提条件的响应将为用户或用户代理提供“足以解决问题的信息”,这是每个RFC 2616的理想情况。

基于RFC 7231的发布更新为替换2616

RFC 7231 旨在取代2616和in 第4.3.3节 描述了POST的可能响应

如果处理POST的结果等于a   现有资源的表示,原始服务器可以重定向   通过发送303(请参阅其他)响应来访问该资源的用户代理   使用“位置”字段中的现有资源标识符。这个   具有为用户代理提供资源标识符的好处   并通过更适合的方法转移表示   共享缓存,但是以用户的额外请求为代价   代理程序尚未缓存表示形式。

现在可能很想在POST重复的情况下简单地返回303。然而,事实恰恰相反。只有多个创建请求(创建不同的资源)返回相同的内容时,返回303才有意义。一个例子是“感谢您提交请求消息”,客户端每次都不需要重新下载。 RFC 7231仍然在4.2.2节中保持POST不是幂等的,并继续保持POST应该用于创建。

有关此内容的更多信息,请阅读此内容 文章


53
2017-10-29 23:00



409冲突响应是否适合尝试使用已存在的用户名创建新帐户?我一直在使用409进行版本冲突,但在阅读完答案之后,我想知道它是否应该用于任何“重复”请求。 - Eric B.
@EricB。是的,在您描述的“由于与当前资源状态发生冲突”的情况下,操作失败。另外,期望用户可以解决冲突并且消息体仅需要通知用户用户名已经存在是合理的。 - Joshcodes
@Joshcodes你能谈谈冲突解决过程吗?在这种情况下,如果用户名已存在,客户端是否会提示最终用户使用其他用户名?如果客户端实际上尝试使用POST来更改用户名,该怎么办? PUT请求是否仍然用于更新参数,而POST用于创建对象,无论是一次一个还是几个?谢谢。 - BFar
@ BFar2如果用户名已经存在,那么客户端应该提示用户。要更改用户名,假设用户名是已创建的资源的一部分,需要修改,PUT将被使用,因为你是正确的,POST用于创建,总是和PUT用于更新。 - Joshcodes
使用简短有效的语言解释事物也是一种理想的技能 - Junchen Liu


我喜欢这个建议 RFC 2616对PUT的定义

POST和PUT请求之间的根本区别体现在Request-URI的不同含义上。 POST请求中的URI标识将处理所包含实体的资源。该资源可能是数据接受过程,某些其他协议的网关或接受注释的单独实体。相反,PUT请求中的URI标识请求附带的实体 - 用户代理知道URI的用途,并且服务器不得尝试将请求应用于其他资源。

这与其他建议相吻合,PUT最适用于已有名称的资源,POST适用于在现有资源下创建新对象(并让服务器为其命名)。

我解释这个,以及对PUT的幂等性要求,意味着:

  • POST适用于在集合下创建新对象(并且创建不需要是幂等的)
  • PUT适用于更新现有对象(并且更新需要是幂等的)
  • POST也可用于对现有对象的非幂等更新(特别是,在不指定整个对象的情况下更改对象的一部分 - 如果您考虑它,创建集合的新成员实际上是这种类型的特殊情况从集合的角度更新)
  • 当且仅当您允许客户端命名资源时,PUT也可用于创建。但是,由于REST客户端不应该对URL结构做出假设,因此这不符合预期的精神。

48
2018-01-11 17:18



“POST也可以用于对现有对象的非幂等更新(特别是,在不指定整个对象的情况下更改对象的一部分”这就是PATCH的用途) - Snuggs