On Fri, 2 Apr 2021, at 21:07, Ilya Khlopotov wrote:
> Nice list of questions. Couple more from me:
>
> # global vs per endpoint?
>
> If we decide for API per endpoint we could different mechanisms to get
> list of supported versions:
> {
> "couchdb": "Welcome",
> "uuid": "85fb71bf700c17267fef77535820e371",
> "vendor": {
> "name": "The Apache Software Foundation",
> "APIs": {
> "/{db}/{docid}": ["4", "55", "95"]
> },
> "version": "1.3.1"
> },
> "APIs": {
> "/{db}/{docid}": ["3", "4", "55"]
> },
> "version": "1.3.1"
> }
> ```
Won't all our client ecosystem will need to be updated to accommodate this
versioning / detection? If so, this should be a simple call, where an API
returns its capabilities early on, and can adjust its settings accordingly.
We already have `GET / {features: "reshard", ...}` and many clients keep
enough state to be able to do a GET /, and make smart decisions from there.
Would that work?
> # return warnings
>
> - there is an expired IETF draft
> https://tools.ietf.org/id/draft-cedik-http-warning-02.html which
> proposes a convention how to inject warnings into JSON response
> - there is a standard Warning header
> https://tools.ietf.org/html/rfc7234#section-5.5.7
> - Warning: 299 api.couchdb.db.doc "Deprecated API: Use v4 instead."
> - vendors could extend it to look like:
> - Warning: 299 api.couchdb.db.doc "Deprecated API: Use v4 instead.
> Old v3 API maintained until 2015-06-02"
The supported API endpoints will be dependent on what people run on their
servers. Rumours of 1.6 and even 1.3 are still out there... we should just put
this in release notes and roll with it.
What do Large Enterprises see around client versioning and deprecations in
other cloud businesses? It can't be much fun.
A+
Dave
