Propagate/wrap error conditions of SPARQL endpoint

[alexdma]

Re openjournals/joss-reviews#2731

If I try to execute a request from my API at http://grlc.io/api/alexdma/getty-linked-data-api/#/processes/get_processes

with application/json as a MIME type, I get an HTTP 200 but with the following payload (seemingly forwarded from the SPARQL endpoint)

{
  "error": {
    "cause": null,
    "stackTrace": [],
    "message": "/sparql?query={URLencoded query}",
    "localizedMessage": "/sparql?query={URLencoded query}",
    "suppressed": []
  },
  "stackTrace": ""
}

The reason seems to be that the Getty SPARQL endpoint will accept application/sparql-results+json but not application/json (if that's what GRLC is sending it as an Accept header). However the original response of the endpoint, as I have tested it, is a HTTP 500.

Falling back to a supported MIME type, or inspecting the JSON schema of the response payload, can be future enhancements nice to have, but I think it is more urgent to propagate error conditions in the response header of GRLC, so that one doesn't get misleading OKs.

Perhaps consider returning a 502 Bad Gateway for these cases, to highlight it is not GRLC's fault.

[c-martinez]

Hi @alexdma! Thanks for raising this issue. Very good point, definitely something to improve there.