You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: