Can a HTTP PATCH request create an resource?

Question

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.

Detrude

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. – Venture

Answer 1

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.

Coniferous

But that RFC also states that "If the Request-URI does not point to an existing resource, the server MAY create a new resource, [...]" – Detrude

@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. – Coniferous

@JimmyT., then is it wise to create a resource in PATCH, rather we should not just say that Resource does not exists? – Afoul

@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 – Detrude

@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. – Neuritis

@Neuritis 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 – Detrude

Answer 2

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.

Moldy