[
https://issues.apache.org/jira/browse/CALCITE-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17121203#comment-17121203
]
Julian Hyde commented on CALCITE-4035:
--------------------------------------
A good specification would be more useful, at this point, than code. We need
one or two examples that include model JSON (similar to [the simple example for
the File
Adapter|https://calcite.apache.org/docs/file_adapter.html#a-simple-example]), a
SQL query, and the REST call that would be generated. [~dhait], could you
create a PR with a new paragraph in {{file_adapter.md}}?
I am interested in how you would tell the adapter which columns can be filtered
and how to generate the REST URI. Is it possible to push other relational
operations (sort, limit, project) into the URI?
Is there a standard or best practice for how URIs are generated? If there is,
let's support only that standard at first.
When we have a good specification, we can figure out whether it can be
implemented in the file adapter. The file adapter already deals with two
orthogonal concerns - the protocol (e.g. file or http) and the result format
(e.g. csv, json, tables embedded in html) - and I think that it can be extended
to handle this case as well. I don't know HAL-HATEOS but it sounds like just
another format.
Anyone have thoughts on testing? How about an embedded Jetty that allows REST
calls onto the scott (emp, dept) data set?
> Adapter for REST interface with query or path parameters
> --------------------------------------------------------
>
> Key: CALCITE-4035
> URL: https://issues.apache.org/jira/browse/CALCITE-4035
> Project: Calcite
> Issue Type: New Feature
> Reporter: David Hait
> Priority: Major
>
> A typical microservice with a REST interface will be queryable by an HTTP GET
> with query parameters or path parameters, and return JSON. It would be
> useful to have an adapter that allows access to this sort of interface. One
> use case would be to allow a join between a database table and a table which
> represents the interface. SQL "where" items could be mapped to specific
> query parameters or path parameters on the web API.
> So, for example,
> {{ SELECT * from service.MyEndpoint where id=123;}}
> could get translated into
> {{ GET http:/service/MyEndpoint/123}}
> or alternatively
> {{ GET [http://service/MyEndpoint?id=123]}}
> The mapping between SQL terms and URL path would be specified in a model
> file.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
