REST API design with async (polling) operations and errors that are found "later"

Question

Given this resource representation:

Request/id/Resource

which is made to support async Resource creation (you submit a Request first, then use the id to poll for Resource until you get 200 OK), what would be a good status code to return when errors of original Request are detected during the polling phase?

Longer explanation:

So the main problem is that submitting the original Request can have some invalid parameters, and for those returning 400 Bad Request is fine. Trouble is, some of these parameters can be validated only later, during the polling phase (while the actual Resource is being created), so we need to propagate this information to the user. What we currently return for errors during the process is 500 InternalServerError, but if we find that something was wrong with the initial Request this is hardly an internal server error. Returning 400 Bad Request comes to mind, but in reality nothing is wrong with the polling call itself (Bad Request for me says that the call you are right now is bad).

Answer 1

I would say don't do it that way. Instead, do something like:

POST /requests
{
    "id": 12,
    "status": "Pending"
}

GET /requests/{id}=12
{
    "id": 12,
    "status": "Error",
    "cause": "Invalid parameter: 'bob' is not a number"
}

GET /requests/{id}=15
{
    "id": 15,
    "status": "Complete",
    "resource": "/resources/5"
}

GET /resources/5
{
    "id": 5,
    ...
} 

GET /requests will return 200 OK and indicate whether there's a problem or not. Clients can poll their request looking for "error" or "resource" (or however you want to structure it - I didn't think much about entities, only URIs).