這是 Django Ninja 系列教學的第 26 篇。
「查詢」是 API 中常見的附加需求，本質上是對資料的過濾（filtering）與篩選。
無論是篩選文章、商品，還是查詢用戶，根據不同條件來過濾資料並獲得結果，可說是大部分專案的必備功能。
在 view 函式中，實作查詢最簡單的方式，就是使用 Django ORM 的過濾方法。例如，我們可以用filter方法來根據特定條件篩選 QuerySet。
這種方法簡單直接，適合基本的查詢需求。然而，它也有其局限性——隨著欄位與需求的增加，查詢條件可能變得越來越複雜，導致程式碼冗長且難以維護。
為了解決這一問題，Django Ninja 提供了 FilterSchema，讓我們可以用更「結構化」的方式，定義並管理查詢條件。
本文將介紹 FilterSchema，一步步實作與講解，讓你了解如何在 Django Ninja 中使用 FilterSchema，實現更加靈活、模組化的 API 查詢功能。
本文所有的程式碼改動，可參考這個 PR。
這是 Django Ninja 系列教學的第 25 篇。
上一篇我們介紹了 Django Ninja 的內建分頁器，並用它實作了簡單的分頁功能。
雖然內建的PageNumberPagination確實方便，但在很多時候，我們仍需要一些客製化功能。
為了實現這個目的，你需要自定義一個分頁類別。
不過別擔心，這種自定義，並非從零開始。而是繼承 Django Ninja 所提供的基礎分頁類別，再進行自己的「加工」。
這篇文章就要來教你怎麼做。
本文所有的程式碼變動，可參考這個 PR。
👉 完整系列目錄：點此查看
👉 程式碼範例：GitHub 範例專案
除了基本的分頁，我們還希望能夠：
page）。per_page）。這無疑是很常見的需求。我們將透過自定義分頁類別，來實現這些功能。
話不多說，直接開始！
這是 Django Ninja 系列教學的第 24 篇。
分頁（pagination）功能，就算在資料量較少的小型專案，也具有相當的重要性。
沒分頁，API 照樣能運作——只是效能會受到影響，特別是在資料量大的情況下。
當 API 一次回傳大量資料時，不僅會增加伺服器負擔，還可能導致客戶端處理緩慢，甚至出現超時或記憶體不足等問題。
透過分頁，我們可以避免一次性傳輸大量資料，提高 API 的效能，同時提升使用者的體驗。
這個主題將分為上、下兩篇，介紹如何在 Django Ninja 中實作分頁功能——從內建的分頁器到自定義分頁類別，以滿足不同需求。
本文所有的程式碼變動，可參考這個 PR。
👉 完整系列目錄：點此查看
👉 程式碼範例：GitHub 範例專案
分頁的核心作用是將大量資料拆分成小部分傳輸，每次只給一些，從而避免效能問題。
具體而言，分頁能夠幫助我們：
因此，無論專案規模大小，實作高效的分頁策略，對 API 的擴充性與使用者體驗，都有明顯幫助。
了解了分頁的重要性後，我們來開始實作吧！
這是 Django Ninja 系列教學的第 23 篇。要開始介紹進階功能了！
現代 Web 服務中，檔案上傳是一個常見的情境。
無論是使用者上傳照片、夾帶附件，檔案上傳都是不可或缺的功能。
本文介紹如何在 Django Ninja 中實現圖片上傳功能，以使用者「上傳大頭貼」（以下都稱為 avatar，因為大頭貼感覺太可愛🥹）API 為例，帶你一步步了解這個過程。
本文所有的程式碼改動，可參考這個 PR。
👉 完整系列目錄：點此查看
👉 程式碼範例：GitHub 範例專案
不過，在此之前，我們要先了解，本章有哪些主題。
對 API 專案而言，進階功能能幫助我們應對複雜場景與大型專案的挑戰。
雖然這是一個入門指南，但我們仍會涵蓋一些常見的進階功能，這些功能不僅提升 API 的靈活性，還能增強了系統效能與使用者體驗。
本章共有 5 篇，介紹 3 個常見的進階功能：
這些技術不僅對大型專案至關重要，也讓你能在 API 開發中，有效應對多變的需求。
這是 Django Ninja 系列教學的第 21 篇。
在軟體開發中，錯誤處理是一個不容忽視——但常常被忽視——的環節。
不誇張地說，錯誤處理是一個「做得好沒人誇，做不好系統就慘兮兮」的議題。
沒關係，我們還是盡可能把自己做好。
Django Ninja 使用 Pydantic 進行資料驗證，失敗時，預設回應「422 Unprocessable Entity」。
然而，我們有時候需要回應「400 Bad Request」或別的狀態碼，以符合現實業務需求或團隊開發習慣。
總之，無論出於何種原因，我們想自訂錯誤訊息、格式，以及回應的狀態碼，而不使用 Django Ninja 預設的 422 回應——不得不說，這個制式回應的資訊有點多、結構有點複雜，因為它要兼容各種情況。
本文將介紹如何自定義錯誤處理與回應——使用 Django Ninja 內建的HttpError。
所有的程式碼改動，可參考這個 PR。
👉 完整系列目錄：點此查看
👉 程式碼範例：GitHub 範例專案
上一篇我們提到，如果你在 Schema 的驗證方法中，拋出ValueError錯誤，Django Ninja 將會自動捕捉並回應。
事實上，不止ValueError，Django Ninja 還會替你處理以下這幾種錯誤：
pydantic.ValidationError，來自 Pydantic 的驗證錯誤，這是為何當 Schema 欄位有問題時，我們會直接收到 422 回應。ninja.errors.ValidationError，這些錯誤同樣會返回 422。ninja.errors.HttpError：這是本文的重點，下面會介紹。這些都是 Django Ninja 會自動捕捉的錯誤，但不是每一種都給出制式的 422 回應——第三種就不是。
這是 Django Ninja 系列教學的第 20 篇。
上一篇我們講完了單一欄位的自定義驗證，這篇則要來討論跨欄位之間的驗證。
跨欄位驗證同樣是 API 開發中十分常見的需求，例如註冊帳號時，要保證「密碼」與「確認密碼」兩個欄位內容相同；選擇日期期間時，開始日期不能晚於結束日期等。
這些驗證場景無法透過單一欄位驗證實現，因為它們需要同時檢查多個欄位之間的邏輯關聯，來確保整體資料的一致性和正確性。
本文將介紹如何透過 Pydantic 來實現跨欄位驗證需求——以「確認密碼」為例，展示這個功能的實際應用。
本文所有的程式碼改動，可參考這個 PR。
👉 完整系列目錄：點此查看
👉 程式碼範例：GitHub 範例專案
其實，無論是單一欄位還是跨欄位的自定義驗證，都不一定要藉由 Pydantic 來完成。
理論上，資料驗證可以直接在 view 函式中進行，例如取出輸入的欄位值，手動驗證它的合法性。跨欄位驗證也是如此。
然而，這是一種方便但「粗糙」的做法——只適合用在驗證邏輯非常單純的情況。
透過 Pydantic 進行資料驗證，則能夠帶來一個明顯的好處：關注點分離。