django下的 restful規範 Drf框架 psotman的安裝使用 及一些容易遺忘的小點

1.經常使用的先後端傳輸數據的方式
    在form表單裏：
	方式一：application/x-www-form-urlencoded
	方式二：multipart/form-data
	上述兩種在後端經過POST獲取對應數據，FILES獲取文件數據

    利用ajax傳輸json類型的數據  
	 contentType:'application/json'    

　　

2.不經過註釋中間件，實現代碼來跨過csrf的功能


  對於fbv而言，  
	from django.views.decorators.csrf import csrf_exempt,csrf_protect
        @csrf_exempt   不校驗
	@csrf_protect   校驗
	
  對於cbv而言：
	csrf_protect  存在三種，而csrf_exempt存在兩種

from django.utils.decorators import method_decorator
from django.views import View
from django.views.decorators.csrf import csrf_exempt,csrf_protect

# @method_decorator(csrf_exempt,name='dispatch')   這是第一種
class Text(View):
    # @method_decorator(csrf_exempt)   第二種
    def dispatch(self, request, *args, **kwargs):
        res = super(Text, self).dispatch(request, *args, **kwargs)
        return res

    def get(self,*args,**kwargs):
        return HttpResponse('ok')

    def post(self,*args,**kwargs):
        return HttpResponse('okl')

　　

3.wsgi協議
  --->按http請求協議解析數據

  --->按http響應協議組裝數據
    	
wsgi協議實際上是定義了一種server與application解耦的規範，django自帶的wsgiref是對該協議的具體實現。

此外，實現該協議的其餘服務器：
    uwsgi:支持較高併發
    wsgiref == java中的tomcat

wsgiref：支持併發量不高，django自帶

　　

4.CBV源碼分析

from app01 import views
  url(r'^text2/',views.Text.as_view())
	請求經過中間件後進入路由--》路由匹配成功，執行後面的類對應的函數--》本質是執行as_view所對應的View類下的閉包函數--》內部調用self.dispatch-->根據請求方式的不一樣，執行不一樣的本身定義的方法。

　　

5.符合restful規範的傳輸json類型的數據


def bookss(request):
    if request.method == 'POST':
        books = models.Books.objects.all()
        li = [{'name':book.name,'publish':book.publish} for book in books]
        response = {'code':100,'msg':'查詢成功','data':li}
        return JsonResponse(response,safe=False,json_dumps_params={'ensure_ascii':False})
    # #safe=False 若是序列化的對象中有列表，須要設置   'ensure_ascii':False  數據中含有中文，須要設置
    return render(request,'book.html')


$('#b1').click(function () {
        $.ajax({
            url:'',
            type:'post',
            contentType: 'application/json',
            data:'',
            success:function (datas) {
                {#alert(datas.name,datas.publish)#}
                console.log(datas.msg);
                console.log(datas.data[0].name);
                console.log(datas.data[0].publish)
            }
        })
    })

　　

6.django自定義表名
class User(models.Model):
    id = models.AutoField(primary_key=True)
    name = models.CharField(max_length=16,db_column='姓名')
    # db_column  改變字段名
    age = models.IntegerField()
    class Meta:
        db_table = "User"
        # db_table  改變表名 

自定義後，仍是能夠經過原先的名字去查詢數據	

　　

7.restful規範

1.REST與技術無關，表明的是一種軟件架構風格，REST是Representational State Transfer的簡稱，中文翻譯爲「表徵狀態轉移」
2.REST從資源的角度類審視整個網絡，它將分佈在網絡中某個節點的資源經過URL進行標識，客戶端應用經過URL來獲取資源的表徵，得到這些表徵導致這些應用轉變狀態
3.REST與技術無關，表明的是一種軟件架構風格，REST是Representational State Transfer的簡稱，中文翻譯爲「表徵狀態轉移」
4.全部的數據，不過是經過網絡獲取的仍是操做（增刪改查）的數據，都是資源，將一切數據視爲資源是REST區別與其餘架構風格的最本質屬性
5.對於REST這種面向資源的架構風格，有人提出一種全新的結構理念，即：面向資源架構（ROA：Resource Oriented Architecture）

　　

8.restful api 設計


1.API與用戶的通訊協議，老是使用HTTPs協議。

2.域名 
https://api.example.com               儘可能將API部署在專用域名（會存在跨域問題）
https://example.org/api/               API很簡單

3.版本
URL，如：https://api.example.com/v1/
請求頭                                                  跨域時，引起發送屢次請求


4.路徑，網絡上任何東西都是資源，均使用名詞表示（可複數）
https://api.example.com/v1/zoos
https://api.example.com/v1/animals
https://api.example.com/v1/employees


5.method
GET      ：從服務器取出資源（一項或多項）
POST    ：在服務器新建一個資源
PUT      ：在服務器更新資源（客戶端提供改變後的完整資源）
PATCH  ：在服務器更新資源（客戶端提供改變的屬性）
DELETE ：從服務器刪除資源

6.過濾，經過在url上傳參的形式傳遞搜索條件
https://api.example.com/v1/zoos?limit=10：指定返回記錄的數量
https://api.example.com/v1/zoos?offset=10：指定返回記錄的開始位置
https://api.example.com/v1/zoos?page=2&per_page=100：指定第幾頁，以及每頁的記錄數
https://api.example.com/v1/zoos?sortby=name&order=asc：指定返回結果按照哪一個屬性排序，以及排序順序
https://api.example.com/v1/zoos?animal_type_id=1：指定篩選條件

7.狀態碼
200 OK - [GET]：服務器成功返回用戶請求的數據，該操做是冪等的（Idempotent）。
201 CREATED - [POST/PUT/PATCH]：用戶新建或修改數據成功。
202 Accepted - [*]：表示一個請求已經進入後臺排隊（異步任務）
204 NO CONTENT - [DELETE]：用戶刪除數據成功。
400 INVALID REQUEST - [POST/PUT/PATCH]：用戶發出的請求有錯誤，服務器沒有進行新建或修改數據的操做，該操做是冪等的。
401 Unauthorized - [*]：表示用戶沒有權限（令牌、用戶名、密碼錯誤）。
403 Forbidden - [*] 表示用戶獲得受權（與401錯誤相對），可是訪問是被禁止的。
404 NOT FOUND - [*]：用戶發出的請求針對的是不存在的記錄，服務器沒有進行操做，該操做是冪等的。
406 Not Acceptable - [GET]：用戶請求的格式不可得（好比用戶請求JSON格式，可是隻有XML格式）。
410 Gone -[GET]：用戶請求的資源被永久刪除，且不會再獲得的。
422 Unprocesable entity - [POST/PUT/PATCH] 當建立一個對象時，發生一個驗證錯誤。
500 INTERNAL SERVER ERROR - [*]：服務器發生錯誤，用戶將沒法判斷髮出的請求是否成功。


更多：http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

8.錯誤處理，應返回錯誤信息，error當作key。
{
    error: "Invalid API key"
}

9.返回結果，針對不一樣操做，服務器向用戶返回的結果應該符合如下規範。

GET /collection：返回資源對象的列表（數組）
GET /collection/resource：返回單個資源對象
POST /collection：返回新生成的資源對象
PUT /collection/resource：返回完整的資源對象
PATCH /collection/resource：返回完整的資源對象
DELETE /collection/resource：返回一個空文檔

10.Hypermedia API，RESTful API最好作到Hypermedia，即返回結果中提供連接，連向其餘API方法，使得用戶不查文檔，也知道下一步應該作什麼。

{"link": {
  "rel":   "collection https://www.example.com/zoos",
  "href":  "https://api.example.com/zoos",
  "title": "List of zoos",
  "type":  "application/vnd.yourformat+json"
}}

摘自：http://www.ruanyifeng.com/blog/2014/05/restful_api.html

　　

9.DRF框架的的介紹


   在序列化與反序列化時，雖然操做的數據不盡相同，可是執行的過程倒是類似的，也就是說這部分代碼是能夠複用簡化編寫的。
    在開發REST API的視圖中，雖然每一個視圖具體操做的數據不一樣，但增、刪、改、查的實現流程基本套路化，因此這部分代碼也是能夠複用簡化編寫的：
        增：校驗請求數據 -> 執行反序列化過程 -> 保存數據庫 -> 將保存的對象序列化並返回
        刪：判斷要刪除的數據是否存在 -> 執行數據庫刪除
        改：判斷要修改的數據是否存在 -> 校驗請求的數據 -> 執行反序列化過程 -> 保存數據庫 -> 將保存的對象序列化並返回
        查：查詢數據庫 -> 將數據序列化並返回


Django REST framework能夠幫助咱們簡化上述兩部分的代碼編寫，大大提升REST API的開發速度。

認識Django REST framework
    Django REST framework 框架是一個用於構建Web API 的強大而又靈活的工具。

    一般簡稱爲DRF框架 或 REST framework。

    DRF框架是創建在Django框架基礎之上，由Tom Christie大牛二次開發的開源項目。

特色：
    提供了定義序列化器Serializer的方法，能夠快速根據 Django ORM 或者其它庫自動序列化/反序列化；
    提供了豐富的類視圖、Mixin擴展類，簡化視圖的編寫；
    豐富的定製層級：函數視圖、類視圖、視圖集合到自動生成 API，知足各類須要；
    多種身份認證和權限認證方式的支持；
    內置了限流系統；
    直觀的 API web 界面；
    可擴展性，插件豐富

　　

10.DRF的安裝使用：

在終端裏的安裝
    pip3 install djangorestframework       （windows環境下，pip會將下載的第三方包存放在如下路徑：[your path]\Python36\Lib\site-packages\中）

    在pycharm下的settings安裝
        
    pycharm下的終端裏經過 pip3 install djangorestframework   下載，直接將該模塊安裝在該項目下的解釋器裏


使用：
           
第一步，在視圖裏，必須寫 CBV
	from rest_framework.views import  APIView
		class Book(APIView):
			pass
第二步：在settings配置
            INSTALLED_APPS= [
					。。。。。
				'rest_framework'
			]

　　

繼承APIView後的源碼分析 ：圖片以下

 

 

 

 

 

結論：

繼承了APIView 以後：
-1 全部的請求都沒有csrf的認證了
-2 在APIView中as_view本質仍是調用了父類View的as_view（View的as_view）
-3 as_view中調用dispatch -----》這個dispatch是APIView的dispatch

 

APIView的dispatch , request的源碼分析

-APIVIew的dispatch方法：
	-1 對原生request對象作了一層包裝（面向對象的封裝），之後再用的request對象都新的request對象
	-2 在APIView中self.initial(request, *args, **kwargs)，裏面有頻率控制，權限控制和認證相關
	-3 根據請求方法執行我們寫的視圖類中的相應方法
		--視圖類中方法的request對象，已經變成了封裝後的request
-Request類：
	-1 原生的request是self._request
	-2 取以post形式提交的數據，從request.data中取（urlencoded，formdata，json格式）
	-3 query_params 就是原生request的GET的數據
	-4 上傳的文件是從FILES中取
	-5 （重點）其餘的屬性，直接request.屬性名（由於重寫了__getattr__方法）


# 必須寫cbv
from rest_framework.views import  APIView
class Books(APIView):
    def get(self,request):
        #request是被封裝後的request,原生的request在request._request
        #若是想用原生requset中的屬性，仍是原來的用法，由於Request重寫了__getattr__方法
        # 原生django只能處理urlencoded和formdata編碼，若是是json格式，原生django是不能處理的，須要本身從body中取出來自行處理
        # request.data 無論前端傳數據的編碼格式是urlencoded，formdata或者是json，都從裏面取值
        # request.data
        #request.query_params  是原來django原生的GET中的數據
        #self.FILES  就是上傳的文件
        dic={'name':'lqz','age':30,'height':178,'wife':['liuyifei','dilireba','egon']}
        return JsonResponse(dic)

　　

 

postman的功能：

    模擬前端向接口發送請求，測試接口

將其數據更美觀的展現出來： https://www.json.cn/