Successful html codes on failure

[organisciak]

When the BookwormAPI fails, it doesn't send an HTML error code for clients to interpret.

Since the most recent commit, I can't find any failed queries from BookwormGUI, so this is low priority, I suppose. Here's a simulated query with an error, which provides a 200 Status Code:

http://bookworm.htrc.illinois.edu/cgi-bin/dbbindings.py?query={%22groups%22:[%22date_year%22],%22counttype%22:%22WordsPerMillion%22,%22words_collation%22:%22Case_Sensitive%22,%22database%22:%22hathipd%22,%22search_limits%22:[{%22word%22:[%22\\\%22],%22date_year%22:{%22$gte%22:1750,%22$lte%22:1923}}],%22method%22:%22return_json%22}

[bmschmidt]

What error code should it throw, do you think?

Is there an argument for wrapping the errors inside JSON instead of using HTML codes?

[organisciak]

Good question. Not sure what the code should be. Perhaps 500? (http://www.w3.org/Protocols/HTTP/HTRESP.html)

The client should interpret the error code from the header: both JQuery's $.ajax and d3's d3.json support error codes. I filed an issue with BookwormGUI to that effect. Conventionally, I do see error codes in JSON often, I'm not certain of the motivation but it might be an attempt to cover edge cases.

[organisciak]

Oh, but of course, error responses as JSON are easier for the client to understand and parse. if (err) { console.error (err.msg) }

The most immediate issue is communicating an error, articulating which error is the next step.

[bmschmidt]

I just realized we're having this discussion on the API repo: it should properly be under the BookwormDB repo, because the API lives there now and this one is deprecated.