Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jsonate_request decorator: return correct http status and error message when errors occur #26

Open
weswil07 opened this issue Nov 29, 2023 · 1 comment
Labels
bug Something isn't working

Comments

@weswil07
Copy link

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.

@weswil07 weswil07 added the bug Something isn't working label Nov 29, 2023
@weswil07
Copy link
Author

weswil07 commented Jan 19, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant