Merge branch 'main' into pre-commit-ci-update-config

Author: ghazi-git

.github/workflows/coverage.yml

@@ -16,7 +16,7 @@ jobs:
       - name: Generate coverage report
         run: |
           pip install .
-          pip install pytest pytest-django pytest-cov
+          pip install django~=3.2 pytest pytest-django pytest-cov drf-spectacular django-filter
           pytest --cov --cov-report=xml
       - name: Upload coverage to Codecov
         uses: codecov/codecov-action@v3

README.md

@@ -98,6 +98,10 @@ to allow you to get more information out of the traceback. You can enable standa
 DRF_STANDARDIZED_ERRORS = {"ENABLE_IN_DEBUG_FOR_UNHANDLED_EXCEPTIONS": True}
 ```
 
+## Integration with DRF spectacular
+If you plan to use [drf-spectacular](https://github.com/tfranzel/drf-spectacular) to generate an OpenAPI 3 schema,
+install with `pip install drf-standardized-errors[openapi]`. After that, check the doc page for configuring the
+integration.
 
 ## Links
 

docs/changelog.md

@@ -5,6 +5,8 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 
 ## [UNRELEASED]
+### Added
+- add support for automatically generating error responses schema with [drf-spectacular](https://github.com/tfranzel/drf-spectacular).
 
 ## [0.11.0] - 2022-06-24
 ### Changed (Backward-incompatible)

docs/conf.py

@@ -51,3 +51,5 @@
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
 # html_static_path = ["_static"]
+
+myst_heading_anchors = 3

docs/index.md

@@ -9,6 +9,8 @@ settings.md
 error_response.md
 customization.md
 gotchas.md
+openapi.md
+openapi_sample_description.md
 contibuting.md
 release.md
 changelog.md

docs/openapi.md

@@ -0,0 +1,107 @@
+# Sample API Description
+
+Check the [Tips and Tricks](openapi.md#hide-error-responses-that-show-in-every-operation) to understand how to use this sample API description.
+
+## Overview
+Here you will probably give an overview of the API and add a description for it.
+
+## Authentication
+Since the API requires authentication, you might want to add a section to describe the authentication flow as well.
+
+## Errors
+Now this is the important section in this example. In this section, you can list the error responses that appear
+in every operation with some explanation. It can go sth like:
+
+### 401 Unauthorized
+These errors are returned with the status code 401 whenever the authentication fails or a request is made to an
+endpoint without providing the authentication information as part of the request. Here are the 2 possible errors
+that can be returned.
+```json
+{
+    "type": "client_error",
+    "errors": [
+        {
+            "code": "authentication_failed",
+            "detail": "Incorrect authentication credentials.",
+            "attr": null
+        }
+    ]
+}
+```
+```json
+{
+    "type": "client_error",
+    "errors": [
+        {
+            "code": "not_authenticated",
+            "detail": "Authentication credentials were not provided.",
+            "attr": null
+        }
+    ]
+}
+```
+
+### 405 Method Not Allowed
+This is returned when an endpoint is called with an unexpected http method. For example, if updating a user requires
+a POST request and a PATCH is issued instead, this error is returned. Here's how it looks like:
+
+```json
+{
+    "type": "client_error",
+    "errors": [
+        {
+            "code": "method_not_allowed",
+            "detail": "Method “patch” not allowed.",
+            "attr": null
+        }
+    ]
+}
+```
+
+### 406 Not Acceptable
+This is returned if the `Accept` header is submitted and contains a value other than `application/json`. Here's how the response would look:
+
+```json
+{
+    "type": "client_error",
+    "errors": [
+        {
+            "code": "not_acceptable",
+            "detail": "Could not satisfy the request Accept header.",
+            "attr": null
+        }
+    ]
+}
+```
+
+### 415 Unsupported Media Type
+This is returned when the request content type is not json. Here's how the response would look:
+
+```json
+{
+    "type": "client_error",
+    "errors": [
+        {
+            "code": "not_acceptable",
+            "detail": "Unsupported media type “application/xml” in request.",
+            "attr": null
+        }
+    ]
+}
+```
+
+### 500 Internal Server Error
+This is returned when the API server encounters an unexpected error. Here's how the response would look:
+
+```json
+{
+    "type": "server_error",
+    "errors": [
+        {
+            "code": "error",
+            "detail": "A server error occurred.",
+            "attr": null
+        }
+    ]
+}
+```

docs/openapi_sample_description.md

@@ -78,3 +78,8 @@ exception with
 instead of `return Response(data, status=500)`. That way, error response formatting is handled automatically for you.
 But, keep in mind that exceptions that result in 5xx response are reported to error monitoring tools (like Sentry)
 if you're using one.
+
+## Integration with DRF spectacular
+If you plan to use [drf-spectacular](https://github.com/tfranzel/drf-spectacular) to generate an OpenAPI 3 schema,
+install with `pip install drf-standardized-errors[openapi]`. After that, check the doc page for configuring the
+integration.

docs/quickstart.md

@@ -19,5 +19,46 @@ DRF_STANDARDIZED_ERRORS = {
     # {field}{NESTED_FIELD_SEPARATOR}{nested_field}
     # for example: 'shipping_address.zipcode'
     "NESTED_FIELD_SEPARATOR": ".",
+
+    # The below settings are for OpenAPI 3 schema generation
+
+    # ONLY the responses that correspond to these status codes will appear
+    # in the API schema.
+    "ALLOWED_ERROR_STATUS_CODES": [
+        "400",
+        "401",
+        "403",
+        "404",
+        "405",
+        "406",
+        "415",
+        "429",
+        "500",
+    ],
+
+    # A mapping used to override the default serializers used to describe
+    # the error response. The key is the status code and the value is a string
+    # that represents the path to the serializer class that describes the
+    # error response.
+    "ERROR_SCHEMAS": None,
+
+    # When there is a validation error in list serializers, the "attr" returned
+    # will be sth like "0.email", "1.email", "2.email", ... So, to describe
+    # the error codes linked to the same field in a list serializer, the field
+    # will appear in the schema with the name "INDEX.email"
+    "LIST_INDEX_IN_API_SCHEMA": "INDEX",
+
+    # When there is a validation error in a DictField with the name "extra_data",
+    # the "attr" returned will be sth like "extra_data.<key1>", "extra_data.<key2>",
+    # "extra_data.<key3>", ... Since the keys of a DictField are not predetermined,
+    # this setting is used as a common name to be used in the API schema. So, the
+    # corresponding "attr" value for the previous example will be "extra_data.KEY"
+    "DICT_KEY_IN_API_SCHEMA": "KEY",
+
+    # should be unique to error components since it is used to identify error
+    # components generated dynamically to exclude them from being processed by
+    # the postprocessing hook. This avoids raising warnings for "code" and "attr"
+    # which can have the same choices across multiple serializers.
+    "ERROR_COMPONENT_NAME_SUFFIX": "ErrorComponent",
 }
 ```