OpenAPI for application management

[tuler]

Defines an openapi for application management of a (future) multi-application node.
It defines 4 endpoints: listing, adding, querying and removing.

Listing is paginated and has filtering based on status.

I used application instead of dapp. We're favoring application in several locations including sunodo codebase and rollups-explorer codebase, because there are several tools that generate names based on that, and the term "DApp", or "dApp" does not behave well with those tools, often generating oddities like d-app, or d_app.

[gligneul]

Looking good

[endersonmaia]

I found no reference to the chain the node is running?

Is it expected to a multi-dapp node to work on multiple chains, of for a single chain?

Anyway, I think some API endpoint (or response header) should expose details for the configuration of the node, the chainID being one of these details.

GET /v1/status
{ "chainID":  "123", "epochDuration": "68000", "applicationCount": 10, ...}

[tuler]

Is it expected to a multi-dapp node to work on multiple chains, of for a single chain?

No. It's single chain.

Anyway, I think some API endpoint (or response header) should expose details for the configuration of the node, the chainID being one of these details.

The process running the API will receive the same env variables as a node would receive.
Aiming for simplicity, I don't think we need to expose this to an endpoint.

[tuler]

"applicationCount": 10

Application count is part of the API in the response of the GET /applications

[gligneul]

Looks good!

[tuler]

Rebased, squashed, renamed file.

[tuler]

Added 204 to DELETE, in case it can be satisfied immediately.
I'm working on the implementation, and it looks like the case will be that we will send a SIGTERM to gracefully shutdown a node, and wait for it to die with some timeout. If it succeeds we can return 204, if it times out we can return a 202. Does it make sense?

[gligneul]

I'm working on the implementation, and it looks like the case will be that we will send a SIGTERM to gracefully shutdown a node, and wait for it to die with some timeout. If it succeeds we can return 204, if it times out we can return a 202. Does it make sense?

So, will it be a sync request? Do you plan to remove the stopping and stopped status?

[tuler]

So, will it be a sync request? Do you plan to remove the stopping and stopped status?

It will be a sync request. If times out the client would have to query the GET until it returns stopped, or if we remove the stopped until it returns 404.

[gligneul]

It will be a sync request. If times out the client would have to query the GET until it returns stopped, or if we remove the stopped until it returns 404.

I see. I don't have strong opinions about the stopped, you can leave it if you want.