NCATSTranslator / ReasonerAPI

NCATS Biomedical Translator Reasoners Standard API
35 stars 28 forks source link

Does a bad /asyncquery still require a job_id to be returned? #424

Open edeutsch opened 1 year ago

edeutsch commented 1 year ago

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.

tokebe commented 1 year ago

Discussion in the architecture call shows agreement that an appropriate HTTP status code is sufficient, after which the response body doesn't have to conform to TRAPI.

edeutsch commented 1 year ago

Let's get some specific documentation in place to address this