-
Notifications
You must be signed in to change notification settings - Fork 11
Description
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/