+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 >>
