couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Supporting API client generation tools (Was: [DISCUSS] couchdb 4.0 transactional semantics)
Date Wed, 22 Jul 2020 16:20:28 GMT


> On 22. Jul 2020, at 14:48, Bessenyei Balázs Donát <bessbd@apache.org> wrote:
> 
> On Tue, 21 Jul 2020 at 18:45, Jan Lehnardt <jan@apache.org> wrote:
>> I’m not sure why a URL parameter vs. a path makes a big difference?
>> 
>> Do you have an example?
>> 
>> Best
>> Jan
>> —
> 
> Oh, sure! OpenAPI Generator [1] and et al. for example generate Java
> methods (like [2] out of spec [3]) per path per verb.
> Java's type safety and the way methods are currently generated don't
> really provide an easy way to retrieve multiple kinds of responses, so
> having them separate would help a lot there.

My argument would be that API generation tools that try to abstract over
HTTP that aren’t able to really abstract over HTTP aren’t our place
to fix ;P

But I wouldn’t be averse to adding endpoints that make this easier for
these tools. Although I’m sceptical they can deal with our continuous
modes anyway. Adding endpoints is not a BC break, and I would not
support removing the original versions. We should identify all places
that would be problematic before deciding either way.

I know a few Cloudant folks have looked at this previously.

I also don’t feel too strongly about this, but I’m happy to have a
discussion on this.

> Donat
> 
> PS. I'm getting self-conscious about discussing this in this thread.
> Should I open a new one?

Done.

Best
Jan
—
> 
> 
> [1] https://openapi-generator.tech/
> [2] https://github.com/OpenAPITools/openapi-generator/blob/c49d8fd/samples/client/petstore/java/okhttp-gson/src/main/java/org/openapitools/client/api/PetApi.java#L606
> [3] https://github.com/OpenAPITools/openapi-generator/blob/c49d8fd/samples/client/petstore/java/okhttp-gson/api/openapi.yaml#L208


Mime
View raw message