在前面的章節我們已經對於Django有了基本的認識，也因此我們能認知Django是能夠直接開發API的。那為什麼我們還需要學習或是使用Django Rest frame（DRF）呢？

今天的重點如下：

• 為什麼需要DRF
• DRF的非同步支援性
• DRF的優缺點
• DRF的未來：是否可能被取代？

為什麼需要DRF

Django我們會說是一個全端框架，主要的目的是要建立完整的Web應用，但是現階段前後端分離還是顯學的現在，DRF更專精在API開發上就是其發揮作用的地方

1. 專注於API：DRF專門建構RESTful API，提供許多Django中沒有的功能或是如果要完成需要額外多寫大量程式碼
2. 序列化器的強大能力：所謂的序列化器就是將特定語言中的資料類型或是對象轉換成可以通過網路傳輸的格式（如XML,JSON），當然Django也能做到，但是面對複雜的數據結構，DRF中的序列化器可以更好的達成目標
3. 認證與權限：在前面深入瞭解Django內置的用戶管理系統中我們已經了解到封裝身份驗證系統的方便了，除了Django也有的BasicAuthentication與SessionAuthentication，DRF還包含TokenAuthentication與JWT認證可供使用
4. DRF在開發API時有自帶瀏覽介面，相比Django開發更方便

雖然全端框架興起，但是大多是提升全棧開發的一致性，例如都是Javascript或是Typescript開發，或是搭配新的Web技術，在效能有提升，又或是在SSR、ISR技術的補強，反之這些都不會是Django的強項，但是因為DRF具備Django強大的ORM，以及完善的驗證與安全系統，在API領域有自己的優勢區間進而讓Django也保持一定的競爭力

DRF的非同步支援性

DRF在Django支援非同步視圖以及最重要的ORM操作也支援非同步後有了更好的支援，提高了部分場景下的性能，不過因為DRF強項的Class-based view（CBV）再加上認證系統，如果納入了非同步可能在開發上也會有許多要注意的地方，如下方的連結：

https://github.com/encode/django-rest-framework/discussions/7774

加上我在應用上沒有實際使用過非同步的CBV，因此就不特別展開介紹了

DRF的優缺點

優點

1. 強大且靈活的序列化器
2. 透過CBV、ViewSet與Router在不需要太多自定義方法的時候，可以大幅簡化實現CRUD的API所需程式碼
3. 與Django的豐富社群無縫接成
4. 適合開發大專案，需要良好認證與安全系統時可以給予較大的支持

缺點

1. 學習曲線更陡峭
2. 性能部分沒有特別優秀
3. 在許多開發情形中可能不需要這樣複雜的開發模式，不夠輕量

DRF的未來：是否可能被取代？

DRF雖然是Django中相當流行的框架，但是確實面臨如FastAPI、Starlette還有同為基於Django的Django Ninja的挑戰，DRF在性能、API設計與非同步支援程度上都沒有特別突出的部分。但是正如同我們前面提到，Django因為DRF還保有一定的競爭力，DRF也因為背後有Django這個老大哥，也還是有自己的優勢區間

雖然在2024學習DRF不一定是一個好的選擇，但是因為他基於Django，所以我覺得DRF還是一個很好的學習錨點，正因為DRF跟Django一樣都是大而全的特性，我們才能在學習的過程能夠更全面的了解開發時的不同面向，讓你在學習其他框架或是語言時有更好的基礎或是對於系統架構更有想法