11

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.

Improve this question
1
  • 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. Commented Dec 23, 2016 at 20:19

2 Answers 2

Reset to default
9

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

But that RFC also states that "If the Request-URI does not point to an existing resource, the server MAY create a new resource, [...]"
@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.
@JimmyT., then is it wise to create a resource in PATCH, rather we should not just say that Resource does not exists?
@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
@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.
|
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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.