Post by rpajak on Jan 4, 2017 12:45:43 GMT
In chapter 6.5.2. "Status codes" it is written "Where the HTTP status code indicates a failure, the response body contains an extended error resource
to provide the client more meaningful and deterministic error semantics". If read directly, in the response body there should always be extended error resource and nothing else.
When client sends PATCH request, but resource was modified in the meantime and ETag doesn't match, 412 status code is returned, so according to above sentence, extended error resource should be returned in the body. Then client performs GET to have up-to-date resource and ETag and then performs PATCH again.
Would it be allowed for the service to include requested resource representation into 412 response body, with @message.ExtendedInfo about ETag mismatch appended? Client's GET would not be needed than.
to provide the client more meaningful and deterministic error semantics". If read directly, in the response body there should always be extended error resource and nothing else.
When client sends PATCH request, but resource was modified in the meantime and ETag doesn't match, 412 status code is returned, so according to above sentence, extended error resource should be returned in the body. Then client performs GET to have up-to-date resource and ETag and then performs PATCH again.
Would it be allowed for the service to include requested resource representation into 412 response body, with @message.ExtendedInfo about ETag mismatch appended? Client's GET would not be needed than.
