3

I need to do asynchronous updates to a resource. Is there definitive statement on whether or not a 202 Accepted is an appropriate response to a PATCH?

The official documentation here, never mentions a 202, and appears to be assuming that resource changes due to a PATCH are made synchronously, but it never makes a definite statement.

What is the appropriate schematics for the PATCH action?

Community
  • 1
  • 1
N_A
  • 19,799
  • 4
  • 52
  • 98

1 Answers1

6

I don't see why returning a 202 is bad. While there is not explicit mention of using 202, the spec does hint to it in the example.

Successful PATCH response to existing text file:

HTTP/1.1 204 No Content Content-Location: /file.txt ETag: "e0023aa4f"

The 204 response code is used because the response does not carry a message body (which a response with the 200 code would have). Note
that other success codes could be used as well.

202 is a success code and it's definition does not prohibit it's use in a PATCH.

10.2.3 202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

As long as you patch atomically and the async request does not leave the resource in a half-patched state, this should be good.

Deepak Bala
  • 11,095
  • 2
  • 38
  • 49