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).

[Neko1313]

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

I agree with the need to create an additional endpoint for API. For example, /v1/meta/list_model, which will allow you to get information about existing models. However, this may not be practical in some cases, because superset stores the names of tables and columns in its database. Knowing them, you can get the necessary information by the model name.

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).
I believe that the correct solution is not to use the existing dialect, since exceptions or specific errors present in Cube. Dev may not be clear if they are replaced with similar ones for PostgreSQL.

[Neko1313]

Hi, @igorlukanin, as promised, tried to make MR in your project for this task.

The only difficulty I've encountered is that it probably won't be possible to quickly implement Swagger for a given project, since the project is written in a certain way. I would like to use tools such as @nestjs/swagger, swagger-ui-express to simplify development, but this can lead to a malfunction of the project.