Mas i1847 putapi #1848
Mas i1847 putapi #1848
Conversation
As the if_not_modified and if_none_match are not supported via the HTTP API for non-consistent PUT - simply build object from a new object, as with PB API.
resource_exists/2 is a key part of the flow for both GET and PUT, as conditional HTTP headers require this check for PUTs. therefore only override resource_exists (and don't fetch) when it is a PUT, and those conditional headers do not exist.
So that delete does not require a fetch
To mimic if_not_modified feature via PB API
To be consistent with other HTTP headers
|
Failure in test |
|
The original intention was to standardise the response to delete - such that HTTP and PB would both respond OK as a result of an attempt to delete an object which is not present. There is a need to be correct with respect to the HTTP standard. However, the HTTP standard is unclear. Some argue, that due to the idempotent requirement - As there is no certainty as to the correctness of the response, and there are other cases where the response (especially error responses) vary between HTTP and PB - it seems better to be consistent with the previous version, rather than be consistent between the APIs. |
Also ensure the timeouts passed in in a delete is respected, and passed through the riak_client to the FSM.
* Never GET before PUT As the if_not_modified and if_none_match are not supported via the HTTP API for non-consistent PUT - simply build object from a new object, as with PB API. * More webmachine friendly override resource_exists/2 is a key part of the flow for both GET and PUT, as conditional HTTP headers require this check for PUTs. therefore only override resource_exists (and don't fetch) when it is a PUT, and those conditional headers do not exist. * Attempt to tidy and refactor delete So that delete does not require a fetch * Pipe-cleaned delete path * Add if_not_modified conflict check To mimic if_not_modified feature via PB API * Use hyphen not underscore To be consistent with other HTTP headers * Revert to 404 on if DELETE not_found Also ensure the timeouts passed in in a delete is respected, and passed through the riak_client to the FSM.
For both PUT and DELETE the behaviour of the HTTP API should be consistent with that of the PB API, in particular it should not do a fetch of the object, unless such a fetch is required to support conditional request headers (e.g. 'if-None-Match').