Enabling Swagger and improving the HTTP API.

[Neko1313]

Is your feature request related to a problem? Please describe.
Every time I need to review the code and documentation to understand how the REST API and GraphQL work, I get frustrated .

Describe the solution you'd like

1. I would like to see Swagger appear, which will allow you to conduct experiments directly from the browser.

2. I would also like the REST API to allow filtering of the received summary data.
   For example, it would be possible to get only data on metrics for all models, or to get all the information for a specific model, knowing only its table name. This would avoid loading a large amount of information at one time, as it happens now.

Additional context
Sample requests

• All information: /v1/meta
• Model information: /v1/meta/{NameModel}
• Information on the model field: /v1/meta/{NameModel}/{Field}

[Neko1313]

Hi, I would really like to implement the feature faster with the new endpoint, but there is no full immersion in the project, if someone can tell me which files are worth looking at for changes, I can do this part myself

[igorlukanin]

@Neko1313 I believe taking a look at this package is a good starting point. Also, please feel free to check contribution guidelines.

I would also like the REST API to allow filtering of the received summary data. For example, it would be possible to get only data on metrics for all models, or to get all the information for a specific model, knowing only its table name. This would avoid loading a large amount of information at one time, as it happens now.

As for the feature idea itself, why do you think this is going be useful? Could you please describe a scenario where you only need a subset of meta information? What kind of an application would you use it for?

[Neko1313]

@igorlukanin This functionality can be useful for integration into user interfaces in order to optimize data transfer. In particular, it can be useful when working with a large number of cubes, when the amount of data becomes redundant.

In addition, I plan to develop an HTTP\dialect for SQLAlchemy in the future, specially adapted for working with Cube.

[igorlukanin]

This functionality can be useful for integration into user interfaces in order to optimize data transfer.

In general, that makes sense. However, in order to make a request like /meta/{cube_name}, you have to know cube_name. Then the question is: how do you know it—without making an API call that gives you a redundantly large response.

I understand that can be done by further changing the API but this is now not part of this suggestion, is it?

HTTP\dialect for SQLAlchemy in the future, specially adapted for working with Cube

I wonder if that would be easier just to use an existing Postgres driver for SQLAlchemy with Cube's SQL API (this is how Preset currently works with Cube, and Preset uses SQLAlchemy under the hood, AFAIK).