This isn't an error, but more an idea for altering current functionality. At present, when a user accesses the GET-request endpoint at /{country_id}/economy/{policy_id}/over/{baseline_policy_id}, the endpoint returns three different 200 OK JSON responses:
The first, containing a status of computing, returns every time a job is first logged, and it appears that every user would receive this when they first send a request
If the request is resent, the user often receives a message indicating their position in a job queue, as well as an average processing time
After that, when the job is completed, the user receives the computed results
From an API design standpoint, I think it may be best to alter this flow in one of two ways:
Option 1: Change the first two outputs so that, instead of a 200 OK, they return with a 202 Accepted so that users can better error-test and determine more programmatically whether or not a job has completed
Option 2: Incorporate more async functionality and merely have the user await a successful return or an error, and in future docs, indicate that this process takes some time; this could even involve returning a 202 Accepted with a merged version of the first two responses, then creating a post-processing handler at a different endpoint that returns a 200 OK or error message, as well as the completed data
This isn't an error, but more an idea for altering current functionality. At present, when a user accesses the GET-request endpoint at
/{country_id}/economy/{policy_id}/over/{baseline_policy_id}
, the endpoint returns three different200 OK
JSON responses:computing
, returns every time a job is first logged, and it appears that every user would receive this when they first send a requestFrom an API design standpoint, I think it may be best to alter this flow in one of two ways:
200 OK
, they return with a202 Accepted
so that users can better error-test and determine more programmatically whether or not a job has completed202 Accepted
with a merged version of the first two responses, then creating a post-processing handler at a different endpoint that returns a200 OK
or error message, as well as the completed data