django_restframework模塊學習

• 2019 年 10 月 6 日
• 筆記

版權聲明：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。

本文鏈接：https://blog.csdn.net/bbwangj/article/details/100973196

一、rest_framework模塊

apps authentication認證 authtoken (package) checks compat decorators documentation exceptions異常 fields字段 filters過濾 generics通用視圖 management (package) metadata元數據 mixins negotiation內容協商 pagination分頁 parsers解析 permissions權限 relations renderers request請求

REST framework 的 Request 類擴展與標準的 HttpRequest，並做了相應的增強，比如更加靈活的請求解析（request parsing）和認證（request authentication）。 1、Request 解析 REST framwork 的 Request 對象提供了靈活的請求解析，允許你使用 JSON data 或 其他 media types 像通常處理表單數據一樣處理請求。 .data request.data 返回請求主題的解析內容。這跟標準的 request.POST 和 request.FILES 類似，並且還具有以下特點： 包括所有解析的內容，文件（file） 和 非文件（non-file inputs）。 支持解析 POST 以外的 HTTP method ， 比如 PUT， PATCH。 更加靈活，不僅僅支持表單數據，傳入同樣的 JSON 數據一樣可以正確解析，並且不用做額外的處理（意思是前端不管提交的是表單數據，還是 JSON 數據，.data 都能夠正確解析）。 .query_params request.query_params 等同於 request.GET，不過其名字更加容易理解。 為了代碼更加清晰可讀，推薦使用 request.query_params ，而不是 Django 中的 request.GET，這樣那夠讓你的代碼更加明顯的體現出 —– 任何 HTTP method 類型都可能包含查詢參數（query parameters），而不僅僅只是 'GET' 請求。 .parsers APIView 類或者 @api_view 裝飾器將根據視圖上設置的 parser_classes 或 settings 文件中的 DEFAULT_PARSER_CLASSES 設置來確保此屬性（.parsers）自動設置為 Parser 實例列表。 [<rest_framework.parsers.JSONParser object at 0x7fa850202d68>, <rest_framework.parsers.FormParser object at 0x7fa850202be0>, <rest_framework.parsers.MultiPartParser object at 0x7fa850202860>] 包含三個解析器 JSONParser，FormParser，MultiPartParser。 注意： 如果客戶端發送格式錯誤的內容，則訪問 request.data 可能會引發 ParseError 。默認情況下， REST framework 的 APIView 類或者 @api_view 裝飾器將捕獲錯誤並返回 400 Bad Request 響應。 如果客戶端發送的請求內容無法解析（不同於格式錯誤），則會引發 UnsupportedMediaType 異常，默認情況下會被捕獲並返回 415 Unsupported Media Type 響應。

2、內容協商 該請求公開了一些屬性，允許你確定內容協商階段的結果。這使你可以實施一些行為，例如為不同媒體類型選擇不同的序列化方案。 .accepted_renderer 渲染器實例是由內容協商階段選擇的。 .accepted_media_type 表示內容協商階段接受的 media type 的字符串。 3、認證（Authentication） REST framework 提供了靈活的認證方式： 可以在 API 的不同部分使用不同的認證策略。 支持同時使用多個身份驗證策略。 提供與傳入請求關聯的用戶（user）和令牌（token）信息。 .user request.user 通常會返回 django.contrib.auth.models.User 的一個實例，但其行為取決於正在使用的身份驗證策略。 如果請求未經身份驗證，則 request.user 的默認值是 django.contrib.auth.models.AnonymousUser 的實例（就是匿名用戶）。 .auth request.auth 返回任何附加的認證上下文（authentication context）。request.auth 的確切行為取決於正在使用的身份驗證策略，但它通常可能是請求經過身份驗證的令牌（token）實例。 如果請求未經身份驗證，或者沒有附加上下文（context），則 request.auth 的默認值為 None。 .authenticators APIView 類或 @api_view 裝飾器將確保根據視圖上設置的 authentication_classes 或基於 settings 文件中的 DEFAULT_AUTHENTICATORS 設置將此屬性（.authenticators）自動設置為 Authentication 實例列表。 注意：調用 .user 或 .auth 屬性時可能會引發 WrappedAttributeError 異常。這些錯誤源於 authenticator 作為一個標準的 AttributeError ，為了防止它們被外部屬性訪問修改，有必要重新提升為不同的異常類型。Python 無法識別來自 authenticator 的 AttributeError，並會立即假定請求對象沒有 .user 或 .auth 屬性。authenticator 需要修復。 .authenticators 其實存的就是當前使用的認證器（authenticator）列表，打印出來大概是這樣： [<rest_framework.authentication.SessionAuthentication object at 0x7f8ae4528710>, <rest_framework.authentication.BasicAuthentication object at 0x7f8ae45286d8>] 可以看到這裡使用的認證器（authenticator）包括 SessionAuthentication 和 BasicAuthentication。 4、瀏覽器增強 REST framework 支持基於瀏覽器的 PUT，PATCH，DELETE 表單。 .method request.method 返回請求 HTTP 方法的大寫字符串表示形式。如 GET,POST…。 透明地支持基於瀏覽器的 PUT，PATCH 和 DELETE 表單。 .content_type request.content_type 返回表示 HTTP 請求正文的媒體類型（media type）的字符串對象（比如： text/plain , text/html 等），如果沒有提供媒體類型，則返回空字符串。 通常不需要直接訪問此屬性，一般都依賴與 REST 框架的默認請求解析行為。 不建議使用 request.META.get('HTTP_CONTENT_TYPE') 來獲取 content type 。 .stream request.stream 返回一個代表請求主體內容的流。 通常不需要直接訪問此屬性，一般都依賴與 REST 框架的默認請求解析行為。 標準的 HttpRequest 屬性 由於 REST framework 的 Request 擴展於 Django 的 HttpRequest，所有其他標準屬性和方法也可用。例如request.META 和 request.session 字典都可以正常使用。

response響應

與基本的 HttpResponse 對象不同，TemplateResponse 對象保留了視圖提供的用於計算響應的上下文的詳細信息。直到需要時才會計算最終的響應輸出，也就是在後面的響應過程中進行計算。 REST framework 通過提供一個 Response 類來支持 HTTP 內容協商，該類允許你根據客戶端請求返回不同的表現形式（如： JSON ，HTML 等）。 Response 是 Django 的 SimpleTemplateResponse 的子類。Response 對象使用數據進行初始化，數據應由 Python 對象（native Python primitives）組成。然後 REST framework 使用標準的 HTTP 內容協商來確定它應該如何渲染最終響應的內容。 當然，也可以不使用 Response 類，直接返回常規 HttpResponse 或 StreamingHttpResponse 對象。 使用 Response 類只是提供了一個更好的交互方式，它可以返回多種格式。 除非由於某種原因需要大幅度定製 REST framework ，否則應該始終對返回 Response 對象的視圖使用 APIView 類或 @api_view 裝飾器。這樣做可以確保視圖執行內容協商，並在視圖返回之前為響應選擇適當的渲染器。 1、創建 response Response() 與普通 HttpResponse 對象不同，您不會使用渲染的內容實例化 Response 對象。相反，您傳遞的是未渲染的數據，可能包含任何 Python 對象。 由於 Response 類使用的渲染器不能處理複雜的數據類型（比如 Django 的模型實例），所以需要在創建 Response 對象之前將數據序列化為基本的數據類型。 你可以使用 REST framework 的 Serializer 類來執行序列化的操作，也可以用自己的方式來序列化。 構造方法: Response(data, status=None, template_name=None, headers=None, content_type=None) 參數： data： 響應的序列化數據。 status： 響應的狀態代碼。默認為200。 template_name： 選擇 HTMLRenderer 時使用的模板名稱。 headers： 設置 HTTP header，字典類型。 content_type： 響應的內容類型，通常渲染器會根據內容協商的結果自動設置，但有些時候需要手動指定。 屬性 .data 還沒有渲染，但已經序列化的響應數據。 .status_code 狀態碼 .content 將會返回的響應內容，必須先調用 .render() 方法，才能訪問 .content 。 .template_name 只有在 response 的渲染器是 HTMLRenderer 或其他自定義模板渲染器時才需要提供。 .accepted_renderer 用於將會返回的響應內容的渲染器實例。 從視圖返迴響應之前由 APIView 或 @api_view 自動設置。 .accepted_media_type 內容協商階段選擇的媒體類型。 從視圖返迴響應之前由 APIView 或 @api_view 自動設置。 .renderer_context 將傳遞給渲染器的 .render() 方法的附加的上下文信息字典。 從視圖返迴響應之前由 APIView 或 @api_view 自動設置。 標準 HttpResponse 屬性 Response 類擴展於 SimpleTemplateResponse，並且響應中也提供了所有常用的屬性和方法。例如，您可以用標準方式在響應中設置 header： response = Response() response['Cache-Control'] = 'no-cache' .render() 與其他任何 TemplateResponse 一樣，調用此方法將響應的序列化數據呈現為最終響應內容。響應內容將設置為在 accepted_renderer 實例上調用 .render(data，accepted_media_type，renderer_context) 方法的結果。 通常不需要自己調用 .render() ，因為它是由 Django 處理的。 reverse返回url routers路由 schemas (package) serializers序列化 settings設置 status狀態碼 templatetags (package) test測試 throttling限速 urlpatterns urls utils (package) validators驗證器 versioning版本控制器 views視圖 viewsets視圖集