When we looked at some of our internal usage data we found that _update had measurably higher adoption than the rendering functions, so we didn’t push so hard on deprecating it yet.
I’d feel better about removing this endpoint if there was a clear plan to provide alternative server-side partial update functionality in a future release. We had some good discussions in GitHub a while back: https://github.com/apache/couchdb/issues/1554 https://github.com/apache/couchdb/issues/1559 It’d be good to review those designs and see if we can advance them to the level of an RFC. I suspect we’re close. +0 > On May 6, 2020, at 10:53 AM, Nick V <vatam...@gmail.com> wrote: > > +1 > > >> On May 6, 2020, at 08:04, Jonathan Hall <fli...@flimzy.com> wrote: >> >> +1 >> >>> On 5/6/20 1:57 PM, Jan Lehnardt 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 >>>
