1. 談談你對restful 規范的理解？
- restful其實就是一套編寫接口的協議，協議規定如何編寫以及如何設置返回值、狀態碼等信息。
- 最顯著的特點：
restful: 給用戶一個url，根據method不同在后端做不同的處理，比如：post 創建數據、get獲取數據、put和patch修改數據、delete刪除數據。
no rest: 給調用者很多url，每個url代表一個功能，比如：add_user/delte_user/edit_user/
- 當然，還有協議其他的，比如：
- 版本，來控制讓程序有多個版本共存的情況，版本可以放在 url、請求頭（accept/自定義）、GET參數
- 狀態碼，200/300/400/500
- url中盡量使用名詞，restful也可以稱為“面向資源編程”
- api標示：
api.luffycity.com
www.luffycity.com/api/
...
.....
2. 你的restful是怎么學的？
- 因為之前公司要寫這樣項目
- 接口
- 公司要做前后端分離的項目
- 公司要做微信小程序的開發
- 所以就開始學習restful規范，看的技術文章 阮一峰的博客學到的規范。
3. 狀態碼都有哪些？
200：請求成功 處理方式：獲得響應的內容，進行處理
403：禁止 處理方式：丟棄
404：沒有找到 處理方式：丟棄
500：服務器內部錯誤 服務器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。一般來說，這個問題都會在服務器端的源代碼出現錯誤時出現。
100：繼續 客戶端應當繼續發送請求。客戶端應當繼續發送請求的剩余部分，或者如果請求已經完成，忽略這個響應。
101： 轉換協議 在發送完這個響應最后的空行后，服務器將會切換到在Upgrade 消息頭中定義的那些協議。只有在切換新的協議更有好處的時候才應該采取類似措施。
102：繼續處理 由WebDAV（RFC 2518）擴展的狀態碼，代表處理將被繼續執行。
201：請求完成，結果是創建了新資源。新創建資源的URI可在響應的實體中得到 處理方式：爬蟲中不會遇到
202：請求被接受，但處理尚未完成 處理方式：阻塞等待
204：服務器端已經實現了請求，但是沒有返回新的信 息。如果客戶是用戶代理，則無須為此更新自身的文檔視圖。 處理方式：丟棄
300：該狀態碼不被HTTP/1.0的應用程序直接使用， 只是作為3XX類型回應的默認解釋。存在多個可用的被請求資源。 處理方式：若程序中能夠處理，則進行進一步處理，如果程序中不能處理，則丟棄
301：請求到的資源都會分配一個永久的URL，這樣就可以在將來通過該URL來訪問此資源 處理方式：重定向到分配的URL
302：請求到的資源在一個不同的URL處臨時保存 處理方式：重定向到臨時的URL
304：請求的資源未更新 處理方式：丟棄
400：非法請求 處理方式：丟棄
401：未授權 處理方式：丟棄
501：服務器無法識別 服務器不支持當前請求所需要的某個功能。當服務器無法識別請求的方法，並且無法支持其對任何資源的請求。
502：錯誤網關 作為網關或者代理工作的服務器嘗試執行請求時，從上游服務器接收到無效的響應。
503：服務出錯 由於臨時的服務器維護或者過載，服務器當前無法處理請求。這個狀況是臨時的，並且將在一段時間以后恢復。
4. method都有哪些？
GET 獲取數據
POST 創建數據
PUT 修改數據
DELETE 刪除數據
5. 常見請求頭有哪些？
Accept
Accept-Charset
Connection
Cookie
Content-Type
Form
Host
Origin
....
詳情請參閱：https://blog.csdn.net/qq_30553235/article/details/79282113
6. 你是用什么開發的restful接口？
使用django rest framework框架。
7. 為什么要使用django rest framework框架？
在編寫接口時可以不適用django rest framework框架，
如果不使用：也可以做，那么就可以django的CBV來實現，開發者編寫的代碼會更多一些。 小知識: CBV（class base views） 就是在視圖里使用類處理請求。 FBV（function base views） 就是在視圖里使用函數處理請求。
如果 使用：內部幫助我們提供了很多方便的組件，我們通過配置就可以完成相應操作，如：
- 序列化，可以做用戶請求數據校驗+queryset對象的序列化稱為json
- 解析器，獲取用戶請求數據request.data，會自動根據content-type請求頭的不能對數據進行解析
- 分頁，將從數據庫獲取到的數據在頁面進行分頁顯示。
還有其他：
- 認證
- 權限
- 訪問頻率控制
- ...
8. rest framework 視圖你都用過哪些基類？
a. 繼承 APIView
這個類屬於rest framework中頂層類，內部幫助我們實現了只是基本功能：認證、權限、頻率控制，但凡是數據庫、分頁等操作都需要手動去完成，比較原始。
class GenericAPIView(APIView)
def post(...):
pass
b. 繼承 GenericViewSet(ViewSetMixin, generics.GenericAPIView)
如果繼承它之后，路由中的as_view需要填寫對應關系 .as_view({'get':'list','post':'create'})
在內部也幫助我們提供了一些方便的方法：
- get_queryset
- get_object
- get_serializer
注意：要設置queryset字段，否則會跑出斷言的異常。
# 只提供增加功能
class TestView(GenericViewSet):
serializer_class = XXXXXXX
def create(self,*args,**kwargs):
pass # 獲取數據並對數據進行操作
c. 繼承
- ModelViewSet
- mixins.CreateModelMixin,GenericViewSet
- mixins.CreateModelMixin,DestroyModelMixin,GenericViewSet
對數據庫和分頁等操作不用我們在編寫，只需要繼承相關類即可。
示例：只提供增加功能
class TestView(mixins.CreateModelMixin,GenericViewSet):
serializer_class = XXXXXXX
類的繼承關系
9. 認證流程？
- 如何編寫？寫類並實現authticate
- 方法中可以定義三種返回值：
- （user,auth），認證成功
- None , 匿名用戶
- 異常 ，認證失敗
- 流程：
- dispatch
- 再去request中進行認證處理
10. 訪問頻率控制
- 匿名用戶，根據用戶IP或代理IP作為標識進行記錄，為每一個用戶在redis中創建一個列表
{
throttle_1.1.1.1:[1526868876.497521,152686885.497521...]
throttle_1.1.1.2:[1526868876.497521,152686885.497521...]
throttle_1.1.1.3:[1526868876.497521,152686885.497521...]
throttle_1.1.1.4:[1526868876.497521,152686885.497521...]
throttle_1.1.1.5:[1526868876.497521,152686885.497521...]
}
每個用戶再來訪問時，需要先去記錄中剔除以及過期時間，再根據列表的長度判斷是否可以繼續訪問。
如何封IP：在防火牆中進行設置
- 注冊用戶，根據用戶名或郵箱進行判斷。
{
throttle_xxxx1:[1526868876.497521,152686885.497521...]
throttle_xxxx2:[1526868876.497521,152686885.497521...]
throttle_xxxx3:[1526868876.497521,152686885.497521...]
throttle_xxxx4:[1526868876.497521,152686885.497521...]
}
每個用戶再來訪問時，需要先去記錄中剔除以及過期時間，再根據列表的長度判斷是否可以繼續訪問。
1分鍾：40次
11. 接口的冪等性？（是否會造成2次傷害）
一個接口通過1次相同的訪問，再對該接口進行N次相同的訪問時候，對資源不造影響，那么就認為接口具有冪等性。
比如：
GET， 第一次獲取結果、第二次也是獲取結果對資源都不會造成影響，冪等。
POST，第一次新增數據，第二次也會再次新增，非冪等。
PUT， 第一次更新數據，第二次不會再次更新，冪等。
PATCH，第一次更新數據，第二次不會再次更新，非冪等。
DELTE，第一次刪除數據，第二次不在再刪除，冪等。
12. Https和Http區別？
端口：
http：80
https: 443
流程：
- 自定義證書
- 認證機構