DRF之REST規範介紹及View請求流程

DRF是什麼?

早期的url設計是毫無章法的,每一個人的思惟方式不同、命名方式不同而致使的url很是的亂，不方便項目的後期維護和擴展。

• 對於請求處理成功或者失敗的返回信息沒有明確的響應信息規範，返回給客戶端的信息每每都是很隨意的

好比這樣的url:

以上這些狀況的出現，致使了不少的問題，讓互聯網的世界變得雜亂不堪，日益複雜且臃腫。所以http協議創始人告訴人們正在錯誤的使用http協議，除了警告，他發表了一篇博客，大概意思就是教你們如何正確使用http協議，如何正肯定義url，這就是REST（Representational State Transfer），總結來,一句話:

• 用url惟必定位資源，用Http請求方式（GET, POST, DELETE, PUT)描述用戶行爲

RESTful Api設計風格

 

能夠看到，url很是簡潔優雅，不包含任何操做，不包含任何動詞，簡簡單單，用來描述服務器中的資源而已，服務器根據用戶的請求方式對資源進行各類操做。而對數據的操做，最多見的就是CRUD（建立，讀取，更新，刪除），經過不一樣的請求方式，就足夠描述這些操做方式了。若是不夠用，Http還有其餘的請求方式呢！好比：PATCH，OPTIONS，HEAD, TRACE, CONNECT。

REST定義返回結果

 REST定義錯誤信息

{
    "error": "Invalid API key"
}

# 經過一個字典，返回錯誤信息。

# 這就是REST，上圖中的url就是根據REST規範進行設計的RESTful api

Django的CBV請求流程

話很少說,看圖,圖看明白就能夠了

注:咱們在剖析看源碼的時候,必定要清楚self是誰,知道self是誰,基本咱們看源碼思路就很是清晰了

Django的rest_framework的APIView就是對View的功能擴展

from django.shortcuts import HttpResponse

import json

from .models import Courses

# 引入APIView
from rest_framework.views import APIView
# Create your views here.


class CoursesView(APIView):  # 繼承APIView而不是原來的View
    def get(self, request):
        courses = list()

        for item in Courses.objects.all():
            course = {
                "title": item.title,
                "description": item.description
            }

            courses.append(course)

        return HttpResponse(json.dumps(courses, ensure_ascii=False))

DRF APIView的請求流程,基於View

能夠看出,改組件是經過重寫dispatch()方法或as_view()方法來實現其功能的