We are now building a third endpoint that accepts an order and triggers work, see #2101.
As we do in that PR, the correct HTTP status for such endpoints being successful would actually not be 200 OK, but 202 Accepted.
Meaning the order was accepted (so maybe basic auth and syntax are okay, otherwise you should get 400 here), but it is not done yet.
- I want to propose that forecasting and scheduling triggering also move to 202. (The GET forecast endpoint already responds with 202 if the job is still running - but the triggering should probably also do 202, not 200)
- Also, we can return not only the job ID, but even a the new job status endpoint which a frontend or client can poll for the actual 200/500 response.
Here is an example I am working with:
return (
dict(
status="ACCEPTED",
message="Sensor data has been accepted for processing.", # this message can be custom to what the job is about
job_monitor_url=job_url,
job_id=job_id,
),
202,
)
We are now building a third endpoint that accepts an order and triggers work, see #2101.
As we do in that PR, the correct HTTP status for such endpoints being successful would actually not be
200 OK, but202 Accepted.Meaning the order was accepted (so maybe basic auth and syntax are okay, otherwise you should get 400 here), but it is not done yet.
Here is an example I am working with: