> application/couchdb needs registering, which is a faff, and isn't appropriate
> imo as we have many different formats of request and response, which a
> content-type ought to capture.
I could be wrong but `application/couchdb;
_v={version_number},application/json` should fall back to json if
> I'd rather see something where we can say "replace these things with newer
> versions,
fall back to v1 for the defaults".
I thought we would use something like:
```
url_handler(<<"_all_dbs">>, 2)-> fun handle_all_dbs_req/1;
url_handler(<<"_all_dbs">>, _)-> fun chttpd_misc:handl
I didn’t read that hard. If memory serves its supposed to be something like
application/json;couchdb._v2 which shouldn’t require registration.
Regardless, being wrong three ways instead of four is fine by me (HIBP
wrong to be clear).
On Mon, Apr 27, 2020 at 5:44 PM Robert Samuel Newson
wrote:
>
As a general direction, I like it, but the specific example of accept/content
doesn't sit right with me.
application/couchdb needs registering, which is a faff, and isn't appropriate
imo as we have many different formats of request and response, which a
content-type ought to capture. From the p
Overall this looks quite good to me. The only thing I'd say is that we
should set our version much earlier so we can eventually rely on this
for selecting an entirely independent implementation. Though that's
not very pressing as once we have the concept embedded we can extend
it as needed.
For th
Hello again everyone,
This is the Final Call for 3.0.1/3.1.0 changes.
Release notes for 3.0.1 are up:
http://docs.couchdb.org/en/latest/whatsnew/3.0.html#version-3-0-1
I'll get to the rel notes for 3.1.0 tomorrow, but it's basically 3.0.1 +
JWT + SM68 support.
We are currently waiting only
I've implemented a PoC for versioned API
https://github.com/apache/couchdb/pull/2832. The code is very ugly but it
demonstrates how it could work.
Best regards,
iilyak
On 2020/04/27 14:55:10, Ilya Khlopotov wrote:
> Hello,
>
> The topic of API versioning was brought in the [Streaming API in
Hi Ilya,
Good idea. Let's continue the discussion about versioning there.
On Mon, Apr 27, 2020 at 12:51 PM Ilya Khlopotov wrote:
>
> Hi Nick,
>
> Thank you for extensive answer.
>
> > API versioning idea in principle sounds good, but can't think of a
> > clean way to do it. /_v2/_all_dbs pattern
Hi Nick,
Thank you for extensive answer.
> API versioning idea in principle sounds good, but can't think of a
> clean way to do it. /_v2/_all_dbs pattern might work,
See separate discussion here
https://lists.apache.org/thread.html/rcc742c0fdca0363bb338b54526045720868597ea35ee6842aef174e0%40%3
It's good to see more activity in the thread. I thought everyone had
lost interest :-) Nice work, Ilya, on the prototype. I think you
picked what I had initially called option D and E. With the exception
that we don't force clients to specify a limit when a max limit is
configured in the settings.
Hello,
The topic of API versioning was brought in the [Streaming API in CouchDB
4.0](https://lists.apache.org/thread.html/ra8d16937cca332207d772844d2789f932fbc4572443a354391663b9c%40%3Cdev.couchdb.apache.org%3E)
thread. The tread proposes to add new API endpoints to introduce a response
structu
11 matches
Mail list logo
