feat(ui-api, digest): enhance DigestDialog and add dedicated endpoint for digest UI

[MartinBelthle]

Fix [ANT-2449] for the back-end part

Endpoint: GET "/private/studies/{study_id}/outputs/{output_id}/digest-ui"

ResponseModel:

class DigestMatrixUI(AntaresBaseModel):
    rowHeaders: t.List[str]
    columns: t.List[str]
    data: t.List[t.List[str]]
    grouped_columns: bool


class DigestUI(AntaresBaseModel):
    area: DigestMatrixUI
    districts: DigestMatrixUI
    flow_linear: DigestMatrixUI
    flow_quadratic: DigestMatrixUI

[sylvlecl]

My interrogations:
we should chose between 2 things for this new endpoint:

• is it only UI related ? in this case we could stick with the "poor" table representation, but we should make it more obvious in the path and in the class names
• is it meant to become an API endpoint ? in that case we need to have a more specific model with better names and probably another structure (not tables everywhere)

[sylvlecl]

DTOs are really front-facing classes which should be close to the web layer, not deep inside the filesystem layer.
We should at least rename them here to not have DTO in the name.

[MartinBelthle]

Okay, I renamed it DigestUI to fit with what we said. But how do you picture the class not being here ?

[sylvlecl]

I don't think this is needed ?

[MartinBelthle]

You talk about the response model ? If so indeed i think it's not needed but why would I remove it ?

[MartinBelthle]

After discussing with Sylvain, we decided that this endpoint will be strictly used by the front-end so we''l had -ui at the end.
If someone wants to use it via API we'll design a new endpoint with the structure Sylvain proposed as it's indeed better for an API user

[hdinia]

After discussing with Sylvain, we decided that this endpoint will be strictly used by the front-end so we''l had -ui at the end. If someone wants to use it via API we'll design a new endpoint with the structure Sylvain proposed as it's indeed better for an API user

I get the intent of marking UI-only endpoints 👍🏼 , but -ui as a suffix breaks REST conventions where URLs represent resources, not their usage. A prefix like /v1/ui/ would be preferable for UI related routes