Thực hành FastAPI: Xử lý dữ liệu và tìm hiểu hệ thống backend (Phần 2)

Trong phần đầu của loạt bài, các khái niệm cơ bản về FastAPI đã được làm rõ, bao gồm việc tạo những endpoint đầu tiên và cách thức vận hành của tham số đường dẫn (path parameter) cũng như tham số truy vấn (query parameter). Tuy nhiên, việc định nghĩa endpoint chỉ là một phần trong quy trình xây dựng API. Hệ thống sau đó cần tiếp nhận dữ liệu từ người dùng, xác thực các yêu cầu gửi đến, cập nhật tài nguyên và liên kết các thành phần khác nhau. Bài viết này sẽ tiếp tục làm rõ các khái niệm trên thông qua dự án Campus Events API. Tương tự như trước, trọng tâm sẽ là việc nắm vững các nguyên lý nền tảng thay vì dàn trải mọi tính năng của FastAPI. 1. Tiếp nối nội dung từ phần trước Chào mừng quay trở lại. Trong Phần 1, dự án Nền tảng Sự kiện Trường học (Campus Events Platform) đã được khởi động bằng FastAPI. Ứng dụng đầu tiên đã được thiết lập, định nghĩa các endpoint và triển khai các phương thức GET, POST cùng với tham số đường dẫn và tham số truy vấn. Ứng dụng hiện có khả năng truy xuất danh sách sự kiện, lọc dữ liệu và tiếp nhận yêu cầu đăng ký. Tuy nhiên, vẫn còn một vấn đề cần giải quyết. Xét tình huống nhà tổ chức sự kiện nhập sai địa điểm của cuộc thi hackathon sắp diễn ra, hoặc quyết định hủy bỏ hoàn toàn sự kiện đó. Ứng dụng cần phải xử lý được những tình huống phát sinh này. Dưới đây là phần tiếp nối nội dung bài viết. 2. Quản lý sự kiện: PUT và DELETE Xem xét lại dự án Campus Events Platform: Phương thức GET đã được sử dụng để truy xuất thông tin sự kiện và POST để gửi yêu cầu đăng ký. Tiếp theo là hai phương thức HTTP bổ sung. Lưu ý: Trong ứng dụng thực tế, các thao tác này sẽ tương tác với cơ sở dữ liệu hoặc hệ thống lưu trữ khác. Nhằm mục đích đơn giản hóa, các ví dụ dưới đây sẽ thể hiện cấu trúc endpoint và dạng phản hồi mà API có thể trả về. Cập nhật một sự kiện: PUT Giả sử sự kiện Campus Hackathon ban đầu được lên lịch vào thứ Bảy, nhưng địa điểm không còn khả dụng và cần chuyển sang Chủ nhật. Hệ thống cần một giải pháp để cập nhật sự kiện hiện có. @app.put("/events/{event_id}") def update_event(event_id: int): return { "message": "Event updated successfully!", "event_id": event_id }Đoạn mã trên sử dụng cú pháp @app.put(). PUT thường được sử dụng để cập nhật một tài nguyên sẵn có. Tham số event_id trong URL xác định cụ thể sự kiện cần cập nhật. Ví dụ hiện tại chỉ trả về thông báo xác nhận. Trong ứng dụng thực tế, hệ thống sẽ tiếp nhận thông tin cập nhật và lưu trữ các thay đổi đó. Hủy bỏ sự kiện: DELETE Xét trường hợp nhà tổ chức quyết định hủy hoàn toàn sự kiện. Hệ thống cần một phương thức để xóa sự kiện đó khỏi nền tảng. @app.delete("/events/{event_id}") def delete_event(event_id: int): return { "message": "Event deleted successfully!", "event_id": event_id }DELETE được sử dụng khi cần xóa bỏ một tài nguyên. Quy trình cơ bản đã hoàn tất. Bốn phương thức HTTP phổ biến nhất trong xây dựng API hiện đã được giới thiệu đầy đủ. Phương thứcChức năngỨng dụng của hệ thốngGETTruy xuất thông tinXem sự kiệnPOSTTạo mới hoặc gửi thông tinĐăng ký sự kiệnPUTCập nhật tài nguyênThay đổi chi tiết sự kiệnDELETEXóa tài nguyênHủy sự kiện Người lập trình không cần học thuộc máy móc từng định nghĩa. Việc liên hệ với các thao tác thực tế của người dùng trên ứng dụng sẽ giúp bản chất của từng phương thức trở nên rõ ràng và dễ tiếp cận hơn. Khi mục đích của các yêu cầu HTTP đã được làm rõ3. Xử lý dữ liệu không hợp lệ: Giới thiệu Pydantic. Xét một tình huống khác. Giả sử nhà tổ chức tiến hành tạo một sự kiện mới. Sau khi điền tên sự kiện, danh mục và địa điểm, thao tác gửi dữ liệu (Submit) được thực hiện. Tuy nhiên, điều gì sẽ xảy ra nếu phần tên sự kiện bị bỏ trống, hoặc một giá trị số bị nhập nhầm vào trường dữ liệu dạng văn bản? Hệ thống không thể tiếp nhận dữ liệu chưa đầy đủ hoặc không thông tin có cấu trúc chuẩn xác được đưa vào ứng dụng. Đây là khâu mà Pydantic phát huy vai trò quan trọng. Pydantic là thư viện Python được sử dụng để xác thực và phân tích cú pháp dữ liệu. FastAPI tích hợp thư viện này nhằm kiểm tra tính hợp lệ của dữ liệu yêu cầu đầu vào. Cơ chế vận hành cụ thể như sau. Giả định ứng dụng yêu cầu mỗi sự kiện mới phải bao gồm ba trường thông tin: Tên sự kiện Danh mục Địa điểm Có thể định nghĩa một mô hình (model) Pydantic như sau: from pydantic import BaseModelclass Event(BaseModel): name: str category: str venue: strNguyên lý hoạt động cụ thể như sau. BaseModel được cung cấp bởi Pydantic. Việc khởi tạo lớp Event kế thừa từ BaseModel cho phép xác định cấu trúc dữ liệu mà ứng dụng yêu cầu. Ba trường thông tin này cũng được chú thích kiểu dữ liệu: name: str biểu thị tên sự kiện phải là chuỗi ký tự (string). category: str biểu thị danh mục phải là chuỗi ký tự. venue: str biểu thị địa điểm phải là chuỗi ký tự. Bước tiếp theo là áp dụng mô hình này vào ứng dụng FastAPI. Tiếp nhận thông tin qua phần thân yêu cầu (request body) Khi người dùng gửi biểu mẫu, giao diện người dùng (frontend) thường gửi thông tin dưới dạng phần thân yêu cầu định dạng JSON. Ví dụ: { "name": "Campus Hackathon", "category": "Technology", "venue": "University Auditorium" }Có thể khởi tạo một điểm cuối (endpoint) tiếp nhận thông tin này: @app.post("/events") def create_event(event: Event): return { "message": "Event created successfully!", "event": event }Cần lưu ý tham số event: Event. Khai báo này thông báo cho FastAPI rằng phần thân yêu cầu gửi đến phải tuân thủ cấu trúc đã được định nghĩa trong mô hình Event. Khi nhận được yêu cầu, FastAPI sử dụng Pydantic để xác thực dữ liệu trước khi thực thi hàm xử lý. Trong trường hợp tên sự kiện bị thiếu, hoặc địa điểm được cung cấp dưới dạng số thay vì chuỗi ký tự: FastAPI sẽ trả về lỗi xác thực thay vì chuyển dữ liệu không hợp lệ tới hàm của điểm cuối. Theo mặc định, dữ liệu yêu cầu không hợp lệ sẽ tạo ra phản hồi mã lỗi HTTP 422 Unprocessable Entity. Điều này giúp loại bỏ yêu cầu phải viết các đoạn mã kiểm tra tính hợp lệ thủ công cho từng trường dữ liệu. Đây chính là ưu thế then chốt của Pydantic: hỗ trợ chuẩn hóa định dạng dữ liệu hợp lệ và cho phép FastAPI tự động xử lý phần lớn quy trình xác thực. 4. Tổng hợp quy trình: Điều gì xảy ra khi một yêu cầu API được gửi tới? Nội dung trên đã khái quát về điểm cuối, phương thức HTTP, tham số, phần thân yêu cầu và cơ chế xác thực. Tuy nhiên, có một câu hỏi mang tính then chốt cần được làm rõ: Khi phía frontend gửi một yêu cầu, điều gì thực sự diễn ra bên trong ứng dụng FastAPI? Quy trình phối hợp vận hành cụ thể như sau. Giả sử một sinh viên truy cập Nền tảng Sự kiện Trường học (Campus Events Platform) và yêu cầu thông tin chi tiết về một p