Open weswil07 opened 10 months ago
UPDATE:
Just discussed this topic again with @igorkramaric. A lot of the functionality we need here has been implemented in knittingfactory through a combination of json_view and APIReqHandler.
We could pull these out of kf and integrate them with jsonate.
The function 'jsonate_request' seems to have been misnamed, because it does not parse json from a request, but it does return a json response. Whereas, json_view actually does the job of parsing json from a request, so it should also be renamed to better indicate what it does. The class APIRequestHandler provides a standardized way for a view function to return either a response ok, or an error message from the server that can be parsed by a javascript client expecting a json response.
We have also implemented some javascript utilities that interface with the responses returned from APIReqHandler, allow the client to call functions on the response, and/or notify the user about the response status. It may be worth it to split these into their own package at some point, should we want to use these server/client interactions across different apps.
Right now when an error occurs in a view using the
@jsonate_request
decorator, we return a default Django error page, which is html. When our (usually javascript) clients consume the response from this view, we receive http status 200 and then encounter a json parse error.We should return the correct http status code and the error message in valid json. Something like
{"message": "error message"}
will interface with javascript errors, and allow us to handle api related errors in a cleaner and more uniform manner.