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.