search

AI-Planning / planning-as-a-service

The newly improved planner (and more) in the cloud.
Apache License 2.0
30 stars 7 forks source link

Incremental retrieval of plans as they are discovered #39

Open jan-dolejsi opened 2 years ago

jan-dolejsi commented 2 years ago

Planners that support multiple plans are penalized by this interface in the eyes of the end user. The planner may have come up with one or multiple plans, but the end-user still stares at a blanc screen.

Rather than the state transition from PENDING to ok, we should support QUEUEING -> INITIALIZING -> SEARCHING_FOR_INITIAL_PLAN -> SEARCHING_FOR_INITIAL_PLAN -> STOPPED -> HTTP404 (when the plans are removed).

The first endpoint post request should return the session/run ID:

POST /package/xyz/solve

{
  "status": "QUEUEING",
  "id": "qwer-qwer-qwer-qwer"
}

GET /package/xyz/solve/qwer-qwer-qwer-qwer

{
  "status": "SEARCHING...",
  "plansFound": 2
}

GET /package/xyz/solve/qwer-qwer-qwer-qwer/plans/1

{
  "actions": [],
  "metric": 123,
  "elapsedTime": 1234
}

Similarly, the client should have the power to stop the planning process and purged all the data:

DELETE /package/xyz/solve/qwer-qwer-qwer-qwer/

Note that that the URL structure does not need to repeat the /package/xyz/solve/ prefix, but if it does not, we have to come up with a different term for it, e.g. /request/qwer-qwer-qwer-qwer/