10

If a PATCH request is applied to a resource that doesn't exist yet, is it then allowed to create the resource or do I need a separate POST/PUT request in that case?

The PATCH request would go to the URL for the resource for example: PATCH /object/1234. If the object with the ID 1234 is in the database I'll create it, otherwise I'll update it.

The PATCH request doesn't contain all fields, that's why I don't use PUT.

Jimmy T.
  • 4,033
  • 2
  • 22
  • 38
  • the behaviour you're describing is precisely the one expected for the PUT. If you are interested in following REST, PATCH should be used only for updating a resource. Conversely, you'll have two verbs, PUT and PATCH being basically the same. – MaVVamaldo Dec 23 '16 at 20:19

3 Answers3

8

RFC 5789 states that PATCH should be used "to modify an existing HTTP resource." It would probably be best to implement a POST/PUT request in order to adhere to the HTTP standards.

Community
  • 1
  • 1
Acontz
  • 471
  • 4
  • 11
  • 11
    But that RFC also states that "If the Request-URI does not point to an existing resource, the server MAY create a new resource, [...]" – Jimmy T. Dec 24 '16 at 01:23
  • @JimmyT. I must've overlooked that part of the document and I suppose you could use it in that way; however, I don't believe that resource creation was the intended purpose of the verb by the author. – Acontz Dec 24 '16 at 02:49
  • @JimmyT., then is it wise to create a resource in PATCH, rather we should not just say that Resource does not exists? – Deeksha Pandit Jun 01 '22 at 18:35
  • @DeekshaPandit I basically want a "create or update". If PATCH fails with 404 then I have to make a second request with a different method but then the resource might have been created in the meanwhile. I basically just want some transactional security which I can't have over multiple HTTP requests – Jimmy T. Jun 04 '22 at 14:55
  • @JimmyT, depending on the use case, the right way could be: 1) PATCH - if 404 then 2) POST - if 409 (already created) then 3) conflict resolution to see if the data to be PATCHed overwrites some existing data or only adds new data to the resource. I adds complexity to the client application, it could require the end-user to decide which resource version to keep. – fllartal Oct 05 '22 at 12:59
  • @fllartal I'm not concerned about the complexity but this will increase the amount of requests and thus impact performance. In my scenario if I go your route I'll get a lot of 404s. Due to the parallel nature I'd also get a lot of 409 – Jimmy T. Oct 06 '22 at 10:30
1

Whilst a server can create a new resource (as explained in Heiko's answer), you'd be advised to only implement conditional PATCH, where a client sends an If-Unmodified-Since or If-Match header, ensuring the patch is applied only to the version of the resource the client thought they were editing. Conditional PATCH requests preclude the idea of editing a non-extant resource. If a client attempts to send a request without a precondition, the correct response is 428 Precondition Required. See RFC 6585.

Community
  • 1
  • 1
Nicholas Shanks
  • 10,623
  • 4
  • 56
  • 80
0

From the RFC5789

The PATCH method affects the resource identified by the Request-URI, and it also MAY have side effects on other resources; i.e., new resources may be created, or existing ones modified, by the application of a PATCH.

So, given above, yes it is allowed to create resource using PATCH if the resource is unavailable for the URI.

Kowser
  • 8,123
  • 7
  • 40
  • 63