Skip to content

Allow exception handler to be used by normal DRF views #233

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

Merged
merged 1 commit into from
Apr 29, 2016

Conversation

joeyespo
Copy link
Contributor

This fixes #218 and also addresses #214.

If the optional JSON_API_UNIFORM_EXCEPTIONS is set to True, all exceptions will respond with the JSON API format. This is how it used to work, but now for non-JSON-API views, the top-level errors object is properly included in the response, fixing #218.

When JSON_API_UNIFORM_EXCEPTIONS is False (the default), non-JSON-API views will respond with the normal DRF error format, addressing #218 in a way that doesn't require views to manually override handle_exception (which is how it was addressed in #222).

* Add top-level 'errors' object to non-JSON-API responses
* Allow configuring the exception handler to be used _only_
  in JSON API views or uniformly across all views
@joeyespo joeyespo force-pushed the error-response-fixes branch from 67e46d8 to f8093e3 Compare April 21, 2016 22:32
@jerel jerel merged commit 9ed6fd3 into django-json-api:develop Apr 29, 2016
@jerel
Copy link
Member

jerel commented Apr 29, 2016

@joeyespo thanks for this!

jerel added a commit that referenced this pull request Apr 29, 2016
* docs: note about importing serializers

* Document ResourceRelatedField and RelationshipView

* Updated pip install instructions for 2.0.0-beta.2

* Add LimitOffsetPagination

* Dont let the offset go into negative space

* Add basic unit test for LimitOffsetPagination

* Support deeply nested includes
Allow skipping of intermediate included models

* Add current tox.ini directory to PYTHONPATH in order to use imports form there
Fix regression on PY3 caused by unicode_literals

* [FEATURE]: support using get_serializer_class on view

* fixed extract_root_meta for lists

* Fixed get_resource_name in case of non-model backed serializer.

Closes #219

* ResourceRelatedField now accepts serializer methods when many=True

* Rename "suggested" posts to "featured" so we can use suggested as many=True

* Updated SerializerMethodResourceRelatedField to allow many=True

Issue #151
Closes #220

* Correct error responses for projects with different DRF-configurations (#222)

* [#214] Add error messages tests.

* [#214] Extract formatting DRF errors.

* Add example view with custom handle_exception.

* Use HTTP 422 for validation error responses.

* Add full example of class-configured json api view.

* Fixed naming that suggested settings were used to inflect relationship names.

JSON_API_FORMAT_RELATION_NAME actually inflected the `type` instead.
The relation name is not changable at this time although if it woudl
be useful to someone it would be fine to implement it.
Closes #136.

* Updated changelog

* Added a doc note to prefer setting resource_name on serializers or models.

Closes #207

* Added get_related_field_name method to RelationshipView

* Added get_related_field_name method to RelationshipView

* Added docs about field_name_mapping

* Updated the readme for testing (#234)

* Allow exception handler to be used by normal DRF views: (#233)

* Add top-level 'errors' object to non-JSON-API responses
* Allow configuring the exception handler to be used _only_
  in JSON API views or uniformly across all views

* Fix included resource type inconsistency (#229)

When setting `resource_name = None`, the related instance's resource
name is used in `relationships`, but `None` is used in `included`.

This is related to #94 and #124

* Fixes #230. Keep write only fields from having an attribute key

* Release v2.0.0

* Update setup.py to classify as production/stable
@joeyespo joeyespo deleted the error-response-fixes branch April 29, 2016 18:51
khornberg pushed a commit to imtapps-dev/django-rest-framework-json-api that referenced this pull request May 2, 2016
…api#233)

* Add top-level 'errors' object to non-JSON-API responses
* Allow configuring the exception handler to be used _only_
  in JSON API views or uniformly across all views
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants