Hey Paul, Thanks for the review on the plugin. I figured I send a response here on the dev alias so as to not spam everyone with github responses.
Design: I did a lot of experimenting with this. The original implementation I found set things up such that a user could specify an endpoint in the config and append args in the query. For instance, you might have an endpoint called facebook which pinged some API at facebook. The query args were the table, and thus the queries looked like: SELECT * FROM facebook.`?field_1=foo&field_2=bar` You could append as much as you wanted so you could theoretically have something like: SELECT * FROM facebook.`/people/who/live/in/washington/json?field_1=foo&field_2=bar` That "table" name is appended to the URL specified in the plugin config to make the actual request. However, after using it for a while, I wasn't loving the implementation and thought it would be better to have sub configs, similar to the idea of workspaces in the dfs plugin. Thus, you can now create a plugin called 'googleapis' and within that, have different APIs. For example: SELECT * FROM googleapis.googlesheets.`?param1=foo¶m2=bar` and SELECT * FROM googleapis.googledoc.`?param1=foo` This seemed a lot more usable than the original implementation and would prevent a proliferation of copies of the plugin if you were querying a bunch of different APIs. I should add that as currently implemented, the API plugin can do POST queries and the user can add params to the POST body. Future Functionality: I intended this plugin really to be an MVP and perhaps something which could be extended for other systems that use HTTP/REST as an interface. If this gets used, and I do think it will, I plan on adding: Support for OAUTH2 Filter pushdown (once the Base framework is committed) Schemas from swagger and/or OpenAPI Does this make sense?
