(app) Introduce configure_api and Post, Get, Delete, Put HttpMethods

[tchaton]

What does this PR do?

After chatting with @lantiga, we thought there is a need to enable users to expose their own API through the App Rest API.

This PR introduces configure_api hook to the LightningFlow and Post, Put, Delete and Get HttpMethods.

from lightning.api import Post
from pydantic import BaseModel

class Model(BaseModel):
    name: str

class FlowAPI(LightningFlow):

    def handler(self, config: Model):
        return {"counter": config.name}

    def configure_api(self):
        return [Post("/api/v1/request", self.handler)]

TODOS: In another PR, rename the queues and unify API with commands.

Does your PR introduce any breaking changes? If yes, please list them.

Before submitting

• Was this discussed/approved via a GitHub issue? (not for typos and docs)
• Did you read the contributor guideline, Pull Request section?
• Did you make sure your PR does only one thing, instead of bundling different changes together?
• Did you make sure to update the documentation with your changes? (if necessary)
• Did you write any new necessary tests? (not for typos and docs)
• Did you verify new and existing tests pass locally with your changes?
• Did you list all the breaking changes introduced by this pull request?
• Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors)

PR review

Anyone in the community is welcome to review the PR.
Before you start reviewing, make sure you have read the review guidelines. In short, see the following bullet-list:

• Is this pull request ready for review? (if not, please submit in draft mode)
• Check that all items from Before submitting are resolved
• Make sure the title is self-explanatory and the description concisely explains the PR
• Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?

Make sure you had fun coding 🙃

cc @Borda

[hhsecond]

@tchaton can you add a valid use case for this feature (that you cannot accomplish with configure_route) in the PR description please (perhaps we could port the same over to the doc as well)?

[tchaton]

Hey @hhsecond,

I am not entirely sure to understand your question. There isn't a configure_route right now.

The use case is to enable users to register their own external API so they can provide ways for their app to interact with the outside world. Similar to a controlplane.

Within the LightningHPO App, I am using it to enable users to fetch structured information about the app. I believe long term this would enable us to create more complex app with a more clearly defined controlplane.

Right now, I am starting to have a slightly different way to see the distributed state. I think the state should stay in the backend and acts to orchestrate the data plane, but the API should acts as the controlplane and enable modifying the state to start works or fetch data from a persistent database.

Best,
T.C

[lantiga]

Looks great, just a few comments

[lantiga]

LGTM

[ethanwharris]

LGTM, tiny comments