From Slack:
Jackson Callaghan (Exploring Agent, Service Provider)
2:20 PM
RE: TRAPI 1.4 Asyncquery status.
Given the spec of AsyncQueryResponse, it's implied that we could return a non-Accepted status, such as in cases of an invalid query. However, job_id is non-nullable. In the event of an invalid query, for instance, something that would fit QueryNotTraversable, is it acceptable to return that status and a description, but not an ID? Or should a junk ID be returned, such as job_id: REJECTED?
New
Chris Bizon (SRI, Ranking Agent)
8:57 AM
@Eric Deutsch (Expander Agent)
please see Jackson's question above
Eric Deutsch (Expander Agent)
9:11 AM
I am thinking that we intended that a bad request would return a 400 or other HTTP code, at which point AsyncQueryResponse and job_id are not required. But I good point to bring up and clarify at the next meeting, thanks.
From Slack:
Jackson Callaghan (Exploring Agent, Service Provider)
2:20 PM
RE: TRAPI 1.4 Asyncquery status.
Given the spec of AsyncQueryResponse, it's implied that we could return a non-Accepted status, such as in cases of an invalid query. However, job_id is non-nullable. In the event of an invalid query, for instance, something that would fit QueryNotTraversable, is it acceptable to return that status and a description, but not an ID? Or should a junk ID be returned, such as job_id: REJECTED?
New
Chris Bizon (SRI, Ranking Agent)
8:57 AM
@Eric Deutsch (Expander Agent)
please see Jackson's question above
Eric Deutsch (Expander Agent)
9:11 AM
I am thinking that we intended that a bad request would return a 400 or other HTTP code, at which point AsyncQueryResponse and job_id are not required. But I good point to bring up and clarify at the next meeting, thanks.