TOSIT-IO / tdp-server

REST API for tdp-lib orchestration
2 stars 2 forks source link

Canonical services endpoints return too many infos #118

Open PaulFarault opened 1 year ago

PaulFarault commented 1 year ago

Canonical endpoints are returning all data from all of their children which isn't necessary and can cause performances issues.

GET /api/v1/service endpoint
[
- {
-   id: string
-   components: [ Component ]  // see schema on next endpoint
-   variables: Object
-   version: string
- }
+ serviceId: string
]

Eventually, it would be nice to add status and readableName for each service (this comment apply for the next endpoints too):

[
  {
    id: string
+   name: string
+   status: enum
-   components: [ Component ]  // see schema on next endpoint
-   variables: Object
-   version: string
  }
]
GET /api/v1/service/{service_id} endpoint
// `Service` schema:
{
  id: string
  components: [
-   {
-     id: string
-     service_id: string
-     variable: Object
-     version: string
-   }
+   componentId: string
  ]
  variables: Object
  version: string
}

As stated before, component could also return status and name.

GET /api/v1/service/{service_id}/component/{component_id} endpoint
// `Component` schema:
{
  id: string
  serviceId: string
  variables: Object
  version: string
}

This schema is ok.

mdrutel commented 1 year ago

Hi Paul, Which values could the new attribute statustake ? And how could we determine the status of a service ?

PaulFarault commented 1 year ago

Which values could the new attribute status take ?

It could be sth like "idle" | "stopped" | "running" | "loading"

how could we determine the status of a service ?

I don't really know how to do so technically (we could discuss it on #116 and #117). It may involve a playbook, checking running process...