+1.

> On 6 May 2020, at 12:57, Jan Lehnardt <j...@apache.org> wrote:
> 
> Hey all,
> 
> it appears we missed an item in our 3.0 deprecations list and we should
> clear this up.
> 
> We have as of yet failed to capture consensus here about the
> deprecation of the _update endpoint. I think we *have* consensus here,
> but we didn’t make it stick in writing.
> 
> To recap: the _update endpoint was added to allow arbitrary data to be
> POSTed to CouchDB and for developers to take whatever and turn that
> into a JSON document that then gets stored into CouchDB. Initially,
> this was added so we can process HTML Form submits. With the advent of
> XHR/fetch in browsers, this is no longer necessary. Another aim at the
> time was allowing legacy data systems that e.g. send XML via HTTP to
> configurable URLs to directly integrate with CouchDB. This is still a
> valid use-case, but easily enough worked around.
> 
> There is also a constant level of confusion with the similarly named
> validate_doc_update feature, which enforces access control and schema
> conformity on all document writes. There is no proposal to deprecate
> this feature at this point and the _update endpoint and functionality
> are fully distinct from validate_doc_update.
> 
> _update is the logical reverse of a _show and we already have
> deprecated that. It follows that we also deprecate _update for the same
> reasons (which I’m not going to rehash here for the 400th time).
> 
> Since this is an API deprecation as per our bylaws[1], please cast your
> votes (or abstain to agree, as per lazy-consensus).
> 
> Best
> Jan “XML, in this economy?” Lehnardt
> —
> [1]: https://couchdb.apache.org/bylaws.html#api
> 

Reply via email to