Differences between APIs - GET before PUT about riak_kv HOT 4 CLOSED

This may be all related to underlying assumptions of webmachine, and the flow chart that webmachine will go through.

Functionality such as if_none_match and if_match are included in the standard webmachine flow. However, that standard flow requires the stage G7 "Resource Exists" to be passed for both GET and POST. If we bypass the check for resource existence, we may well bypass inherent features for conditional handling of HTTP headers.

Some features that may have to be handled explicitly in the PB API, may be handled implicitly by webmachine.

from riak_kv.

The riak_kv_wm_object module has to cover both GET, PUT and DELETE. Reviewing the code, there are some tricky issues for these flows.

On the GET path, one issue is that the content-type of an object returned, should be the content-type of the object which was used when it was PUT.

The natural place to fetch the resource in the webmachine flow is v3g7 - resource_exists/2. However, this only occurs after validation, including validation of the encoding the client says it will accept. However, the inbound Accept-Encoding on the request cannot be validated until the object has been fetched (and we know what content-type it is to be presented back as).

To try and ensure this works there is an ensure_doc/2 functions that does the GET, only if there is not an object (i.e doc) already on the context. This ensure_doc/2 is then called in its natural place on resource_exists/2, but also at any validation stage that may require knowledge of the content returned from the fetch. The ensure_doc/2 means the GET only occurs once, when ever information about the document is first needed.

Some of the exportable functions needed in validation such as encodings_provided are also required as part of the PUT path (e.g. to return_body). these functions may be called either before or after resource_exists on both GET and PUT. therefore we cannot simply ignore this when the method is PUT/POST.

from riak_kv.

For DELETE, the same initial path in webmachine applied as for GET. This means that DELETE will also try and GET the resource prior to calling riak_client:delete/4 or riak_client:delete_vclock/4.

This means a further unnecessary GET, but also means that {error, notfound} is treated as a failure - whereby on the PB API {error, notfound} leads to a positive response, on the basis that the object is not there (even though it not being there is potentially unexpected).

from riak_kv.

Replacing with #1849.

This issue misunderstands the workings of webmachine. The problem is better explained in kv1849.

from riak_kv.