[GitHub] iilyak commented on issue #820: Add support for queries in /{db}/_all_docs POST
iilyak commented on issue #820: Add support for queries in /{db}/_all_docs POST
URL: https://github.com/apache/couchdb/issues/820#issuecomment-372874974
+1
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] iilyak commented on issue #820: Add support for queries in /{db}/_all_docs POST
iilyak commented on issue #820: Add support for queries in /{db}/_all_docs POST
URL: https://github.com/apache/couchdb/issues/820#issuecomment-363618280
> Why is one better than the other?
1. With one to one mapping between request and response the client library
for static language wouldn't need a factory pattern. For example
`com.google.gson.JsonParser` for Java requires passing a POJO class to the
`gson.fromJson` method. The call look like `gson.fromJson(entry.getValue(),
MyPOJO.class);`. It is more complex when response mutate.
2. The API becoming expressible using OpenAPI Specification if the response
structure is independent from:
- posted content
- query parameters
There are quite a few interesting possibilities if we can express our API
with OpenAPI Specification:
- we can generate tests to check our input validation automatically
- there are testing tools to ensure that there are no API changes (they
work as MITM proxy). We can use this to make sure that:
1) All APIs are documented in docs
2) The API specification is in sync with implementation
3) We are aware of incompatibilities between different versions of spec
- we can generate some parts of libraries for different languages
automatically
- we can generate code to validate input data passed to endpoints
- we can embed required access roles into spec in order to generate rules
for `chttpd_auth_request`. Which simplifies security audit of the code.
- we can generate boilerplate code for endpoints if decide to switch to
another http server.
However this is off topic and should be discussed in ML.
I am aware that there are few precedents in CouchDB which return different
responses based on either posted data or query parameters.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] iilyak commented on issue #820: Add support for queries in /{db}/_all_docs POST
iilyak commented on issue #820: Add support for queries in /{db}/_all_docs POST
URL: https://github.com/apache/couchdb/issues/820#issuecomment-363568339
@wohali: This issue originally was about `_all_docs` only. I have an
implementation of new endpoints `_all_docs_view_query` /
`_desing_docs_view_query` / `_local_docs_view_query` already.
However I am contemplating with the idea to remove `_desing_docs_view_query`
and `_local_docs_view_query`. On the grounds that:
1. The issue was originally about `_all_docs` only. Which indicates that
there is probably no immediate need for `_design_docs` and `_local_docs`
2. Adding 3 new endpoints is more verbose. Although the difference is 8
lines or so.
3. There are probably very few `_design` docs and user can use
`_design_docs` endpoint directly to get them all and filter on client side.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] iilyak commented on issue #820: Add support for queries in /{db}/_all_docs POST
iilyak commented on issue #820: Add support for queries in /{db}/_all_docs POST
URL: https://github.com/apache/couchdb/issues/820#issuecomment-363460739
@ricellis Which one is preferable in terms of support in libraries and
OpenAPI Specification:
- `_all_docs/_query` / `_desing_docs/_query` / `_local_docs/_query`
- `_all_docs_query` / `_desing_docs_query` / `_local_docs_query`
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] iilyak commented on issue #820: Add support for queries in /{db}/_all_docs POST
iilyak commented on issue #820: Add support for queries in /{db}/_all_docs POST
URL: https://github.com/apache/couchdb/issues/820#issuecomment-363455322
Thank you @wohali
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] iilyak commented on issue #820: Add support for queries in /{db}/_all_docs POST
iilyak commented on issue #820: Add support for queries in /{db}/_all_docs POST
URL: https://github.com/apache/couchdb/issues/820#issuecomment-363143122
This introduces a problem with API consistency. Because the response schema
changes depending on what is POSTed. This makes it quite hard to interact with
from static type languages.
It is unfortunate we merged it already. @wohali is it really needed? If so
would you be ok if we move the implementation to separate endpoint?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
