一、Restful API

可以總結為一句話，REST是所有Web應用都應該遵守的架構設計指導原則，面向資源是REST最明顯的特征

1.1、設計規(guī)范

資源

統(tǒng)一接口

url

無狀態(tài)

這里著重說一下無狀態(tài)，什么是無狀態(tài)，即所有資源都可以通過URL定位，而且這個定位與其他的資源無關，也不會因為其他資源的變化而變化。

1.2、Http常用動詞

GET 從服務器獲取資源

POST 在服務器創(chuàng)建資源或者更新資源

PUT 更新資源（客戶端提供改變后所有資源）

PATCH 更新資源 （客戶端提供改變的屬性）

DELETE 刪除資源

HEAD 獲取數(shù)據(jù)的元數(shù)據(jù)

OPTIONS 獲取信息

1.3、網(wǎng)絡請求狀態(tài)碼

2開頭 （請求成功）表示成功處理了請求的狀態(tài)代碼。

200   （成功）  服務器已成功處理了請求。 通常，這表示服務器提供了請求的網(wǎng)頁。 
201   （已創(chuàng)建）  請求成功并且服務器創(chuàng)建了新的資源。 
202   （已接受）  服務器已接受請求，但尚未處理。 
203   （非授權信息）  服務器已成功處理了請求，但返回的信息可能來自另一來源。 
204   （無內容）  服務器成功處理了請求，但沒有返回任何內容。 
205   （重置內容） 服務器成功處理了請求，但沒有返回任何內容。
206   （部分內容）  服務器成功處理了部分 GET 請求。

3開頭 （請求被重定向）表示要完成請求，需要進一步操作。 通常，這些狀態(tài)代碼用來重定向。

300   （多種選擇）針對請求，服務器可執(zhí)行多種操作。 服務器可根據(jù)請求者 (user agent) 選擇一項操作，或提供操作列表供請求者選擇。 
301   （永久移動）請求的網(wǎng)頁已永久移動到新位置。 服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。
302   （臨時移動）服務器目前從不同位置的網(wǎng)頁響應請求，但請求者應繼續(xù)使用原有位置來進行以后的請求。
303   （查看其他位置） 請求者應當對不同的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。
304   （未修改） 自從上次請求后，請求的網(wǎng)頁未修改過。 服務器返回此響應時，不會返回網(wǎng)頁內容。 
305   （使用代理） 請求者只能使用代理訪問請求的網(wǎng)頁。 如果服務器返回此響應，還表示請求者應使用代理。 
307   （臨時重定向）  服務器目前從不同位置的網(wǎng)頁響應請求，但請求者應繼續(xù)使用原有位置來進行以后的請求。

4開頭 （請求錯誤）這些狀態(tài)代碼表示請求可能出錯，妨礙了服務器的處理。

400   （錯誤請求） 服務器不理解請求的語法。 
401   （未授權） 請求要求身份驗證。 對于需要登錄的網(wǎng)頁，服務器可能返回此響應。 
403   （禁止） 服務器拒絕請求。
404   （未找到） 服務器找不到請求的網(wǎng)頁。
405   （方法禁用） 禁用請求中指定的方法。 
406   （不接受） 無法使用請求的內容特性響應請求的網(wǎng)頁。 
407   （需要代理授權） 此狀態(tài)代碼與 401（未授權）類似，但指定請求者應當授權使用代理。
408   （請求超時）  服務器等候請求時發(fā)生超時。 
409   （沖突）  服務器在完成請求時發(fā)生沖突。 服務器必須在響應中包含有關沖突的信息。 
410   （已刪除）  如果請求的資源已永久刪除，服務器就會返回此響應。 
411   （需要有效長度） 服務器不接受不含有效內容長度標頭字段的請求。 
412   （未滿足前提條件） 服務器未滿足請求者在請求中設置的其中一個前提條件。 
413   （請求實體過大） 服務器無法處理請求，因為請求實體過大，超出服務器的處理能力。 
414   （請求的 URI 過長） 請求的 URI（通常為網(wǎng)址）過長，服務器無法處理。 
415   （不支持的媒體類型） 請求的格式不受請求頁面的支持。 
416   （請求范圍不符合要求） 如果頁面無法提供請求的范圍，則服務器會返回此狀態(tài)代碼。 
417   （未滿足期望值） 服務器未滿足"期望"請求標頭字段的要求。

5開頭（服務器錯誤）這些狀態(tài)代碼表示服務器在嘗試處理請求時發(fā)生內部錯誤。 這些錯誤可能是服務器本身的錯誤，而不是請求出錯。

500   （服務器內部錯誤）  服務器遇到錯誤，無法完成請求。 
501   （尚未實施） 服務器不具備完成請求的功能。 例如，服務器無法識別請求方法時可能會返回此代碼。 
502   （錯誤網(wǎng)關） 服務器作為網(wǎng)關或代理，從上游服務器收到無效響應。 
503   （服務不可用） 服務器目前無法使用（由于超載或停機維護）。 通常，這只是暫時狀態(tài)。 
504   （網(wǎng)關超時）  服務器作為網(wǎng)關或代理，但是沒有及時從上游服務器收到請求。 
505   （HTTP 版本不受支持） 服務器不支持請求中所用的 HTTP 協(xié)議版本。

二、Django Rest Framework

這個軟件包可以在Django的基礎上迅速實現(xiàn)API，用以構建WEB API，并且自身還帶有WEB的測試頁面，方便測試自己的API。

官方文檔

https://q1mi.github.io/Django-REST-framework-documentation/

安裝

pip install djangorestframework

2.1、序列化

序列化可以把查詢集和模型對象轉換為json、xml或其他類型，也提供反序列化功能，也就是把轉換后的類型轉換為對象或查詢集。

REST框架中的序列化程序與Django Form 和 ModelForm 類的?作?式?常相似。官方提供了?個 Serializer 類，它為您提供了?種強?的通??法來控制響應的輸出，以及?個 ModelSerializer 類，它提供了?個有?的快捷?式來創(chuàng)建處理模型實例和查詢集的序列化程序。

2.1.1、聲明序列化器

app/my_serializer.py

from rest_framework import serializers

class StudentsSerializer(serializers.Serializer):
    stu_num = serializers.CharField()
    stu_name = serializers.CharField()
    stu_gender = serializers.CharField()

2.1.2、常用fileld類

核心參數(shù)

參數(shù)名	缺省值	說明
read_only	False	只允許序列化輸出
required	True	反序列化必須存在該字段
default		缺省值
allow_null	False	是否允許傳入NULL
validators	[]	函數(shù)列表驗證器
error_messages	{}	一個錯誤信息字典

常用字段

字段名	說明
BooleanField	對應于django.db.models.?elds.BooleanField
CharField	max_length - 驗證輸?包含的字符數(shù)不超過此數(shù)量。 min_length - 驗證輸?包含不少于此數(shù)量的字符。 allow_blank- 如果設置為True則空字符串視為有效值。如果設置為False則空字符串報錯，默認為False。 trim_whitespace- 如果設置為True則會修剪前導和尾隨空格。默認為True
EmailField	EmailField(max_length=None, min_length=None, allow_blank=False)
IntegerField	max_value 驗證提供的數(shù)字是否不?于此值。 min_value 驗證提供的數(shù)字是否不低于此值。
FloatField	max_value 驗證提供的數(shù)字是否不?于此值。 min_value 驗證提供的數(shù)字是否不低于此值。
DateTimeField	format - 格式字符串可以是顯式指定格式的Python strftime格式 input_formats - 表示可?于解析?期的輸?格式的字符串列表

2.1.3、創(chuàng)建serializer對象

定義好Serializer類后，就可以創(chuàng)建Serializer對象了。Serializer的構造?法為

Serializer(instance=None, data=empty, **kwarg)

1） ?于序列化時，將模型類對象傳?instance參數(shù)
2） ?于反序列化時，將要被反序列化的數(shù)據(jù)傳?data參數(shù)
3） 除了instance和data參數(shù)外，在構造Serializer對象時，還可通過context參數(shù)額外添加數(shù)據(jù)，如

serializer = UserSerializer(User, context={'request': request})

2.1.4、序列化實例

settings.py

INSTALLED_APPS = [
    'rest_framework',
]

models.py

class Students(models.Model):
    username = models.CharField(max_length=20)
    password = models.CharField(max_length=20)

    class Meta:
        db_table = 'user'

my_serializer.py

from rest_framework import serializers

class StudentsSerializer(serializers.Serializer):
    username = serializers.CharField()
    password = serializers.CharField()

views.py

class sertest(APIView):
    def get(self, request):
        stu = Students.objects.all().first()
        ser = StudentsSerializer(instance=stu)
        return Response(ser.data)

我們在我們的前端頁面可以得到結果

{
    "username": "tom",
    "password": "123"
}

2.2、反向序列化

使?序列化器進?反序列化時，需要對數(shù)據(jù)進?驗證后，才能獲取驗證成功的數(shù)據(jù)或保存成模型類對象。在獲取反序列化的數(shù)據(jù)前，必須調?is_valid()?法進?驗證，驗證成功返回True，否則返回False。

驗證失敗，可以通過序列化器對象的errors屬性獲取錯誤信息，返回字典，包含了字段和字段的錯誤。如果是?字段錯誤，可以通過修改REST framework配置中的NON_FIELD_ERRORS_KEY來控制錯誤字典中的鍵名。

驗證成功，可以通過序列化器對象的validated_data屬性獲取數(shù)據(jù)。在定義序列化器時，指明每個字段的序列化類型和選項參數(shù)，本身就是?種驗證?為。

2.2.1、單字段驗證

validate_<field_name>(self, value)

2.2.2、多字段驗證

validate(self, attrs):

2.2.3、實例

my_serializer.py

class StudentsSerializer(serializers.Serializer):
    username = serializers.CharField()
    password = serializers.CharField()

    def validated_username(self, value):
        if value[0] == '_':
            raise serializers.ValidationError('不允許下劃線開頭')
        return value

    def validate(self, attrs):
        username = attrs['username']
        password = attrs['password']
        if len(username) > len(password):
            raise serializers.ValidationError('密碼長度過短')
        return attrs

views.py

class sertest(APIView):
    def post(self, request):
        data = request.POST
        ser = StudentsSerializer(data=data)
        print(ser.is_valid())
        return Response({'code': 200})

我們POSTMAN發(fā)送請求，發(fā)現(xiàn)反悔了我們希望的數(shù)據(jù)，而且serializer的數(shù)據(jù)為True，也就是數(shù)據(jù)通過了驗證

2.2.4、保存

如果在驗證成功后，想要基于validated_data完成數(shù)據(jù)對象的創(chuàng)建，可以通過實現(xiàn)create()和update()兩個?法來實現(xiàn)。

my_serializer.py

class StudentsSerializer(serializers.Serializer):
    username = serializers.CharField()
    password = serializers.CharField()

    def validated_username(self, value):
        if value[0] == '_':
            raise serializers.ValidationError('不允許下劃線開頭')
        return value

    def validate(self, attrs):
        username = attrs['username']
        password = attrs['password']
        if len(username) > len(password):
            raise serializers.ValidationError('密碼長度過短')
        return attrs

    def create(self, validated_data):
        return Students.objects.create(**validated_data)

    def update(self, instance, validated_data):
        '''instance 為要更新的對象實例'''
        instance.username = validated_data.get('username')
        instance.password = validated_data.get('password')
        instance.save()
        return instance

views.py

保存

class sertest(APIView):
    def post(self, request):
        data = request.POST
        ser = StudentsSerializer(data=data)
        if ser.is_valid():
            ser.save()
            return Response({'code': 200})
        return Response({'code': 400})

更新

class sertest(APIView):
    def post(self, request):
        data = request.POST
        stu = Students.objects.get(username=data.get('username'))
        # 更新和直接保存的區(qū)別在于這里我們還需要傳入我們需要更新的Query
        ser = StudentsSerializer(data=data, instance=stu)
        if ser.is_valid():
            ser.save()
            return Response({'code': 200})
        return Response({'code': 400})

2.3、ModelSerializer

ModelSerializer類能夠讓你?動創(chuàng)建?個具有模型中相應字段的Serializer類。這個ModelSerializer類和常規(guī)的Serializer類?樣，不同的是：

它根據(jù)模型?動?成?組字段。

它?動?成序列化器的驗證器，?如unique_together驗證器。

它默認簡單實現(xiàn)了.create()?法和.update()?法。

my_serializer.py

class StudentsSerializer(serializers.ModelSerializer):
	class Meta:
		model = Students
		# 包含模型中所有字段
		field = '__all__'
        # 包含模型中指定字段
        fields = ('username', 'password')
        # 排除模型中指定字段，這里需要注意，即使是排除一個字段，也需要加逗號，因為是一個迭代器
        exclude = ('username',)
        # 指明只讀字段
        read_only_fields = ('username',)
        # 添加額外參數(shù)
        extra_kwargs = {
            'bread': {'min_value': 0, 'required': True},
			'bcomment': {'min_value': 0, 'required': True},
        }

三、Request和Response

3.1、Request

REST框架引?了?個擴展了常規(guī)HttpRequest的Request對象，并提供了更靈活的請求解析。Request對象的核?功能是request.data屬性，它與request.POST類似，但對于使?Web API更為有?。REST framework 提供了Parser解析器，在接收到請求后會?動根據(jù)Content-Type指明的請求數(shù)據(jù)類型（如JSON、表單等）將請求數(shù)據(jù)進?parse解析，解析為類字典對象保存到Request對象中。Request對象的數(shù)據(jù)是?動根據(jù)前端發(fā)送數(shù)據(jù)的格式進?解析之后的結果。?論前端發(fā)送的哪種格式的數(shù)據(jù)，我們都可以以統(tǒng)?的?式讀取數(shù)據(jù)。

3.1.1、data屬性

request.data 返回解析之后的請求體數(shù)據(jù)。類似于Django中標準的
request.POST 和 request.FILES 屬性，但提供如下特性：

包含了解析之后的?件和??件數(shù)據(jù)
包含了對POST、PUT、PATCH請求?式解析后的數(shù)據(jù)
利?了REST framework的parsers解析器，不僅?持表單類型數(shù)據(jù)，也?持JSON數(shù)據(jù)

request.POST 只適?于’POST’?法。request.data 處理任意數(shù)據(jù)，適?于’POST’，'PUT’和’PATCH’?法

3.1.2、query_params 查詢參數(shù)

request.query_params 與Django標準的 request.GET 相同，只是更換了更正確的名稱?已。

3.1.3、method

request.method 返回請求的HTTP?法的 ?寫字符串表示形式。

3.2、Response

REST framework提供了?個響應類 Response ，使?該類構造響應對象時，響應的具體數(shù)據(jù)內容會被轉換（render渲染）成符合前端需求的類型。

Response(data, status=None, template_name=None, headers=None, content_type=None)
參數(shù)說明:
data: 為響應準備的序列化處理后的數(shù)據(jù)；
status: 狀態(tài)碼，默認200；
template_name: 模板名稱，如果使?HTMLRenderer 時需指明；
headers: ?于存放響應頭信息的字典；
content_type: 響應數(shù)據(jù)的Content-Type，通常此參數(shù)?需傳遞，REST framework會根據(jù)前端所需類型數(shù)據(jù)來設置該參數(shù)。

四、wrapping

這種方式可以幫助我們用函數(shù)的方式寫視圖

?于基于函數(shù)視圖的@api_view裝飾器。?于基于類視圖的APIView類。

from rest_framework.decorators import api_view

@api_view(['GET', 'POST']) 
def snippet_list(request):
	pass

其實學到這里我們已經基本掌握了怎么返回一個序列化的數(shù)據(jù)以及怎么處理一個序列化的數(shù)據(jù)，下面的基于CBV的操作只是在很大程度上方便我們的操作而已。

五、基于類的視圖CBV

REST framework 提供了眾多的通?視圖基類與擴展類，以簡化視圖的編寫。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-7kilcl0z-1645102778685)(\image-24162874681234687.png)]

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-sCNLcdsM-1645102778686)(\image-87243978127349.png)]

5.1、APIView

APIView是DRF的基類，它?持GET POST PUT DELETE等請求類型,且各種類型的請求之間，有了更好的分離在進?dispatch分發(fā)之前，會對請求進?身份認證，權限檢查，流量控制。繼承?Django的 View ?類。 APIView 與 View 的不同之處在于

傳?到視圖?法中的是REST framework的 Request 對象，?不是Django的HttpRequeset 對象；
視圖?法可以返回REST framework的 Response 對象，視圖會為響應數(shù)據(jù)設置（render）符合前端要求的格式；
任何 APIException 異常都會被捕獲到，并且處理成合適的響應信息；
在進?dispatch()分發(fā)前，會對請求進?身份認證、權限檢查、流量控制。

支持定義的屬性

authentication_classes 列表或元組，身份認證類

permissoin_classes 列表或元祖，權限檢查類

throttle_classes 列表或元祖，流量控制類

5.2、mixins

使?基于類的視圖的?個最?的好處就是我們可以靈活的選擇各種View，使我們的開發(fā)更加的簡潔。mixins??對應了ListModelMixin，CreateModelMixin， RetrieveModelMixin，UpdateModelMixin，DestroyModelMixin。

視圖?法可以返回REST framework的 Response 對象，視圖會為響應數(shù)據(jù)設置（render）符合前端要求的格式；
任何 APIException 異常都會被捕獲到，并且處理成合適的響應信息；
在進?dispatch()分發(fā)前，會對請求進?身份認證、權限檢查、流量控制。

支持定義的屬性

authentication_classes 列表或元組，身份認證類

permissoin_classes 列表或元祖，權限檢查類

throttle_classes 列表或元祖，流量控制類

5.2、mixins

使?基于類的視圖的?個最?的好處就是我們可以靈活的選擇各種View，使我們的開發(fā)更加的簡潔。mixins??對應了ListModelMixin，CreateModelMixin， RetrieveModelMixin，UpdateModelMixin，DestroyModelMixin。