FastAPI เป็นเฟรมเวิร์ค Python สมัยใหม่สำหรับสร้าง API อย่างรวดเร็ว โดยใช้ type hints, การตรวจสอบค่า และเอกสาร OpenAPI อัตโนมัติ เรียนรู้พื้นฐานและการใช้งาน

FastAPI เป็นเฟรมเวิร์คของ Python สำหรับสร้างเว็บ API อย่างรวดเร็ว ด้วยโค้ดที่ชัดเจนและเอกสารอัตโนมัติ คุณเขียนฟังก์ชันเล็ก ๆ (เรียกว่า “endpoint”) ที่ระบุว่าข้อมูลที่ API รับเข้าและส่งออกเป็นอย่างไร แล้ว FastAPI จะจัดการเรื่องเครือข่าย—routing, การตรวจสอบค่า และการสร้างการตอบเป็น JSON ให้
API คือชุด URL ที่ให้ซอฟต์แวร์หนึ่งคุยกับอีกตัวหนึ่งได้
ตัวอย่าง แอปพยากรณ์อากาศบนมือถืออาจเรียก GET /weather?city=Berlin เซิร์ฟเวอร์ตอบด้วยข้อมูลที่มีโครงสร้าง (มักเป็น JSON) เช่น อุณหภูมิและพยากรณ์ แอปไม่ต้องเข้าถึงฐานข้อมูลโดยตรง—มันขอข้อมูลจาก API แล้วแสดงผล
FastAPI ช่วยให้คุณสร้าง URL และการตอบเหล่านั้นด้วย Python ได้ง่ายขึ้น
คุณไม่จำเป็นต้องเชี่ยวชาญ async เพื่อเริ่ม; เขียน endpoint แบบเรียบง่ายไปก่อน แล้วค่อยใช้แนวทางขั้นสูงขึ้นเมื่อระบบโตขึ้น
FastAPI ได้รับความนิยมเพราะลดแรงเสียดทานที่เกิดขึ้นบ่อยเมื่อสร้าง API ใน Python
โปรเจกต์ API แบบดั้งเดิมมักเริ่มด้วยการตั้งค่าช้าและโค้ด “plumbing” มากมาย:
ฟีเจอร์หลักของ FastAPI มุ่งแก้ปัญหาเหล่านี้โดยตรง ทำให้ทีมใช้เวลาออกแบบ endpoint มากขึ้นและเสียเวลาน้อยลงกับโค้ดโครงสร้าง
FastAPI พึ่งพา Python type hints อย่างหนัก เมื่อคุณประกาศฟิลด์เป็น int, optional หรือ list[...] FastAPI จะใช้ข้อมูลนี้ในการตรวจสอบค่าและกำหนดรูปแบบการส่งออก
สิ่งนี้ลดความผิดพลาดจากการใช้ชนิดข้อมูลไม่สม่ำเสมอ และส่งเสริมพฤติกรรมของ endpoint ที่คาดเดาได้มากขึ้น มันยังคงเป็น Python แต่มีความคาดหวังที่ชัดเจนในลายเซ็นของฟังก์ชัน
เพราะ schema ของ API มาจากโค้ด FastAPI จึงสามารถสร้างเอกสารโต้ตอบได้อัตโนมัติ (OpenAPI + Swagger UI/ReDoc) นี่มีประโยชน์สำหรับการทำงานร่วมกัน: นักพัฒนาหน้า, QA และผู้รวมระบบสามารถสำรวจ endpoint ทดลองคำขอ และเห็นโมเดลที่ชัดเจนโดยไม่ต้องรอเอกสารแยกต่างหาก
FastAPI จะไม่แก้ปัญหา API ที่ออกแบบไม่ดี คุณยังต้องตั้งชื่อดี จัดการเวอร์ชัน จัดการข้อผิดพลาด และตัดสินใจเรื่องความปลอดภัย สิ่งที่ FastAPI ให้คือเส้นทางที่ชัดเจนจาก “ไอเดีย” ไปสู่ “API ที่นิยามชัด” โดยมีความประหลาดใจน้อยลง
FastAPI ดูเรียบง่ายเมื่อคุณเข้าใจแนวคิดหลักไม่กี่อย่าง คุณไม่ต้องท่องจำรายละเอียดภายใน—แค่รู้ชิ้นส่วนที่ใช้ทุกวัน
Framework คือชุดเครื่องมือและข้อตกลงสำหรับสร้าง API โดยไม่ต้องเริ่มจากศูนย์ FastAPI ให้ "plumbing" สำหรับงาน API ทั่วไป: นิยาม endpoint, อ่านอินพุต, คืนเอาต์พุต, จัดการข้อผิดพลาด และจัดโค้ดให้ง่ายต่อการดูแล
Routing คือการจับคู่ URL และ HTTP method ไปยังโค้ด Python
ตัวอย่าง คุณอาจ routing GET /users ให้กับการ "list users" และ POST /users ให้กับการ "create a user" ใน FastAPI มักนิยาม route ด้วย decorator อย่าง @app.get(...) และ @app.post(...) ซึ่งอ่านได้ง่ายว่าระบบของคุณมีอะไรบ้าง
การเรียก API แต่ละครั้งเป็น request (สิ่งที่ไคลเอนต์ส่งมา) และ response (สิ่งที่เซิร์ฟเวอร์ตอบ)
FastAPI ช่วยให้คุณ:
/users/{id}), query string (?page=2), headers และ request body200, 201, 404)FastAPI รันบน ASGI มาตรฐานสมัยใหม่สำหรับเซิร์ฟเวอร์เว็บใน Python ซึ่งหมายความว่า FastAPI ถูกออกแบบให้จัดการการเชื่อมต่อจำนวนมากอย่างมีประสิทธิภาพ และรองรับคุณสมบัติเช่นการเชื่อมต่อระยะยาว (เช่น WebSockets) เมื่อจำเป็น โดยไม่ต้องจัดการเครือข่ายระดับต่ำด้วยตัวเอง
Type hints ใน Python (เช่น str, int, list[Item]) ใน FastAPI ไม่ใช่แค่เอกสาร — แต่เป็นข้อมูลสำคัญที่ FastAPI ใช้เพื่อเข้าใจสิ่งที่คาดหวัง แปลงค่าอินพุต และสร้าง API ที่คาดเดาได้
Pydantic ช่วยให้คุณกำหนดรูปร่างของข้อมูล (ฟิลด์ ชนิด ค่าที่ไม่จำเป็น) ในที่เดียว FastAPI ใช้โมเดลเหล่านี้เพื่อตรวจสอบ JSON ที่เข้ามา ปฏิเสธข้อมูลไม่ถูกต้องด้วยข้อความข้อผิดพลาดที่ช่วยให้เข้าใจ และแปลงผลลัพธ์ให้ออกมาอย่างสม่ำเสมอ — ทำให้ API ของคุณทำงานได้เสถียรแม้ไคลเอนต์จะส่งข้อมูลที่ไม่สะอาด
แอป FastAPI สร้างขึ้นรอบ ๆ endpoints: path ของ URL บวกกับ HTTP method คิดว่า endpoint เป็น “สิ่งที่ไคลเอนต์ขอ” และ “วิธีที่มันขอ” เช่น ไคลเอนต์อาจ GET /users เพื่อดึงรายชื่อผู้ใช้ หรือ POST /users เพื่อสร้างผู้ใช้
Path คือ route และ method คือการกระทำ:
GET /products → ดึงข้อมูลPOST /products → ส่งข้อมูลเพื่อสร้างPUT /products/123 → แทนที่/อัปเดตDELETE /products/123 → ลบFastAPI แยกข้อมูลที่เป็นส่วนหนึ่งของ path ออกจากข้อมูลที่เป็นตัวกรองหรือการควบคุมที่ไม่จำเป็น
GET /users/42 → 42 คือ user ID? และมักจะเป็นค่าที่ไม่จำเป็น
GET /users?limit=10&active=true → limit และ active ควบคุมผลลัพธ์เมื่อไคลเอนต์ส่งข้อมูลเชิงโครงสร้าง (มักเป็น JSON) จะอยู่ใน request body มักใช้กับ POST หรือ PUT
ตัวอย่าง: POST /orders พร้อม JSON เช่น { "item_id": 3, "quantity": 2 }.
FastAPI สามารถคืน Python object ธรรมดา (เช่น dict) ได้ แต่เด่นจริง ๆ เมื่อคุณกำหนด response model โมเดลนั้นทำหน้าที่เป็นสัญญา: ฟิลด์มีรูปแบบสม่ำเสมอ ข้อมูลส่วนเกินสามารถถูกกรองออก และชนิดถูกบังคับ ผลลัพธ์คือ API ที่สะอาดและไคลเอนต์รู้ว่าจะคาดหวังอะไร
“Async” (ย่อมาจาก asynchronous) คือวิธีให้ API ของคุณจัดการคำขอจำนวนมากได้อย่างมีประสิทธิภาพเมื่องานส่วนใหญ่ต้องรอ
ลองจินตนาการเป็นบาริสต้า ถ้าต้องยืนอยู่เฉย ๆ จนกาแฟเสร็จ จะให้บริการได้น้อยกว่า ถ้าทำแบบที่ดีกว่า คือเริ่มกาแฟแล้วไปรับออเดอร์ถัดไป ในทำนองเดียวกัน async ให้แอปเริ่มงานที่ต้องรอ (เช่น คำขอเครือข่าย) แล้วไปจัดการคำขออื่นได้
Async เหมาะเมื่อ API ของคุณทำงาน I/O มาก — งานที่ใช้เวลารอแทนการประมวลผล เช่น:
ถ้า endpoint ของคุณรองานเหล่านี้บ่อย ๆ async จะช่วยให้ throughput ดีขึ้นและลดโอกาสคำขอคิวแน่นเมื่อโหลดสูง
Async ไม่ใช่ปุ่มวิเศษสำหรับทุกอย่าง หาก endpoint เน้นการคำนวณหนัก (เช่น ย่อรูปภาพขนาดใหญ่ ประมวลผลข้อมูลวิทย์ข้อมูล หรือการเข้ารหัส payload ขนาดใหญ่) async จะไม่เร่งการคำนวณ ในกรณีนี้ควรใช้แนวทางอื่น (background workers, process pools, หรือการขยาย horizontally)
คุณไม่จำเป็นต้องเขียนใหม่ทั้งหมดเพื่อใช้ FastAPI คุณสามารถเขียนฟังก์ชัน route แบบ synchronous (def) แล้ว FastAPI จะรันให้ได้ หลายโปรเจกต์ผสมทั้งสองแบบ: เก็บ endpoint ง่าย ๆ เป็น synchronous และใช้ async def เมื่อเหมาะสม (เช่น รอบการเรียกฐานข้อมูลหรือ HTTP ขาออก)
การตรวจสอบค่าเป็นด่านแรกระหว่างโลกภายนอกกับโค้ดของคุณ เมื่อ API รับอินพุต (JSON body, query params, path params) คุณต้องมั่นใจว่าข้อมูลครบ ถูกชนิด และอยู่ในขอบเขตที่เหมาะสม ก่อนเขียนฐานข้อมูล เรียกบริการอื่น หรือเริ่มตรรกะทางธุรกิจ
FastAPI พึ่งพา Pydantic ในเรื่องนี้ คุณอธิบายว่า "ข้อมูลที่ดี" เป็นอย่างไรครั้งเดียว แล้ว FastAPI จะ:
ถ้าไคลเอนต์ส่งข้อมูลผิดโครง FastAPI จะตอบด้วย 422 Unprocessable Entity พร้อม payload ข้อผิดพลาดที่ชี้ฟิลด์และสาเหตุ ทำให้ไคลเอนต์แก้ไขได้ง่ายขึ้น
นี่คือตัวอย่างโมเดลเล็ก ๆ ที่แสดงฟิลด์จำเป็น ชนิด ข้อจำกัด min/max และรูปแบบ:
from pydantic import BaseModel, EmailStr, Field
class UserCreate(BaseModel):
email: EmailStr
age: int = Field(ge=13, le=120)
username: str = Field(min_length=3, max_length=20)
email ต้องมีage ต้องเป็นจำนวนเต็มage อยู่ระหว่าง 13–120EmailStr บังคับรูปแบบอีเมลที่ถูกต้องโมเดลเดิมสามารถใช้กำหนดเอาต์พุตได้ด้วย ดังนั้นการตอบของ API จะไม่รั่วฟิลด์ภายในโดยไม่ตั้งใจ คุณคืน Python object; FastAPI (ผ่าน Pydantic) แปลงเป็น JSON ที่มีชื่อฟิลด์และชนิดถูกต้อง
หนึ่งในฟีเจอร์ที่ใช้งานได้จริงของ FastAPI คือมันสร้างเอกสาร API ให้โดยอัตโนมัติ — จากโค้ดที่คุณเขียนแล้ว
OpenAPI คือมาตรฐานในการอธิบาย API ในรูปแบบที่เครื่องอ่านได้ (มักเป็น JSON) คิดว่าเป็น "สัญญา" ที่ระบุ:
GET /users/{id})เพราะมันอ่านได้โดยเครื่อง จึงมีเครื่องมือใช้สร้างไคลเอนต์ทดสอบ ตรวจสอบคำขอ และช่วยให้ทีมสอดคล้องกัน
FastAPI เสิร์ฟหน้าเอกสารสองแบบสำหรับคนโดยอัตโนมัติ:
ในโปรเจกต์ FastAPI ทั่วไป คุณจะเจอที่:
/docs (Swagger UI)/redoc (ReDoc)เมื่อคุณเปลี่ยน path parameters, request models, response models หรือกฎการตรวจสอบ ค่า OpenAPI schema (และหน้าดอก) จะอัปเดตอัตโนมัติ ไม่มีขั้นตอนบำรุงรักษาเอกสารแยกต่างหาก
แอป FastAPI สามารถเล็กมากและยังรู้สึก "จริง" ได้ คุณนิยามออบเจกต์ Python ชื่อ app เพิ่ม route สองสามตัว แล้วรันเซิร์ฟเวอร์ท้องถิ่นเพื่อลองในเบราว์เซอร์
ตัวอย่างเล็กที่สุดที่มีประโยชน์คือ:
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
def read_root():
return {"message": "Hello, FastAPI"}
แค่นี้: route หนึ่ง (GET /) ที่คืน JSON
เพื่อให้รู้สึกเหมือน API จริง ลองเก็บ items ในลิสต์ นี่ไม่ใช่ฐานข้อมูล—ข้อมูลจะหายเมื่อเซิร์ฟเวอร์รีสตาร์ท—แต่เหมาะสำหรับการเรียนรู้
from fastapi import FastAPI
app = FastAPI()
items = []
@app.post("/items")
def create_item(name: str):
item = {"id": len(items) + 1, "name": name}
items.append(item)
return item
@app.get("/items")
def list_items():
return items
คุณสามารถ:
POST /items?name=Coffee เพื่อเพิ่ม itemGET /items เพื่อดึงรายการโครงสร้างเริ่มต้นทั่วไปคือ:
main.py (สร้าง app และกำหนด routes)requirements.txt หรือ pyproject.toml (dependencies)โดยทั่วไปคุณจะ:
uvicorn main:app --reload)http://127.0.0.1:8000 และลอง endpointFastAPI “dependencies” คืออินพุตที่ใช้ร่วมกันที่ endpoint ต้องการ—เช่น session ฐานข้อมูล ผู้ใช้ที่ล็อกอิน การตั้งค่าแอป หรือพารามิเตอร์ทั่วไป แทนที่จะสร้างหรือแยกพารามิเตอร์เหล่านี้ในทุก route คุณกำหนดครั้งเดียวแล้วให้ FastAPI จัดการส่งให้เมื่อจำเป็น
Dependency มักเป็นฟังก์ชัน (หรือคลาส) ที่คืนค่าซึ่ง endpoint ใช้ FastAPI จะเรียกมันให้ คุณไม่ต้องเรียกด้วยตัวเอง และ FastAPI จะดูว่ามันต้องการอะไร (จากพารามิเตอร์) แล้วฉีดผลลัพธ์ให้ฟังก์ชันของคุณ
นี้เรียกว่า dependency injection แต่คุณอาจคิดว่าเป็น: “ประกาศสิ่งที่ต้องการ แล้ว FastAPI จะจัดการเชื่อมให้”
ถ้าไม่มี dependencies คุณอาจ:
ด้วย dependencies คุณรวมตรรกะเหล่านี้ไว้ที่เดียว ถ้าคุณเปลี่ยนวิธีสร้าง session DB หรือโหลดผู้ใช้ปัจจุบัน ก็แก้ที่เดียวไม่ต้องแก้หลาย endpoint
page/limit และการตรวจสอบรูปแบบที่คุณจะเห็นบ่อยในแอป FastAPI:
from fastapi import Depends, FastAPI
app = FastAPI()
def get_settings():
return {"items_per_page": 20}
@app.get("/items")
def list_items(settings=Depends(get_settings)):
return {"limit": settings["items_per_page"]}
คุณประกาศ dependency ด้วย Depends(...) แล้ว FastAPI จะส่งผลลัพธ์เข้าไปในพารามิเตอร์ endpoint วิธีเดียวกันใช้ได้กับ building blocks ที่ซับซ้อนกว่า (เช่น get_db() หรือ get_current_user())
FastAPI ไม่ได้ “ปิดความปลอดภัย” ให้โดยอัตโนมัติ — คุณเลือกสกีมแล้วเดินระบบเข้ากับ endpoints ของคุณ ข่าวดีก็คือ FastAPI มีเครื่องมือพื้นฐาน (โดยเฉพาะผ่านระบบ dependencies) ที่ทำให้รูปแบบความปลอดภัยทั่วไปใช้งานได้ง่าย
Authentication ตอบคำถาม: “คุณเป็นใคร?” Authorization ตอบคำถาม: “คุณทำอะไรได้บ้าง?”
ตัวอย่าง: ผู้ใช้อาจพิสูจน์ตัวตนได้ (login/token ถูกต้อง) แต่ยังไม่มีสิทธิ์เข้าถึง route เฉพาะผู้ดูแล
X-API-Key) ต้องจัดการการหมุนและยกเลิกFastAPI สนับสนุนรูปแบบเหล่านี้ผ่านยูทิลิตี้เช่น fastapi.security และจะบันทึกไว้ใน OpenAPI ด้วย
ถ้าคุณเก็บรหัสผ่านผู้ใช้ อย่าเก็บเป็นข้อความธรรมดา ให้เก็บเป็น hash ที่มี salt และช้า (เช่น bcrypt/argon2 โดยใช้ไลบรารีที่เชื่อถือได้) และพิจารณา rate limiting และนโยบายล็อกบัญชี
ความปลอดภัยขึ้นกับรายละเอียด: การเก็บโทเค็น การตั้งค่า CORS, HTTPS, การจัดการความลับ และการตรวจสอบ authorization ในทุก endpoint ที่สำคัญ ใช้ตัวช่วยเป็นจุดเริ่มต้น แต่ต้องทดสอบและตรวจสอบก่อนใช้งานจริง
การทดสอบช่วยให้คำมั่น "มันใช้งานได้บนเครื่องฉัน" กลายเป็นความมั่นใจที่พร้อมส่ง ข่าวดีก็คือ FastAPI สร้างบน Starlette ดังนั้นคุณจะได้เครื่องมือทดสอบที่ดีโดยไม่ต้องตั้งค่าเยอะ
Unit tests เน้นชิ้นเล็ก: ฟังก์ชันที่คำนวณค่า, dependency ที่โหลดผู้ใช้ปัจจุบัน, หรือเมธอดบริการที่ติดต่อฐานข้อมูล (มักจะ mocking)
Integration tests ทดสอบ API แบบครบวงจร: เรียก endpoint แล้วตรวจ HTTP response ทั้งหมด การทดสอบแบบนี้จะจับข้อผิดพลาดด้าน routing, dependency wiring, และการตรวจสอบค่า
ชุดทดสอบที่ดีมักมี unit tests มากกว่า (เร็ว) และ integration tests น้อยกว่า (ความมั่นใจสูง)
สามารถทดสอบแอป FastAPI “เหมือนไคลเอนต์” โดยใช้ TestClient ของ Starlette ซึ่งส่งคำขอไปยังแอปภายในกระบวนการเดียว — ไม่ต้องรันเซิร์ฟเวอร์
from fastapi.testclient import TestClient
from app.main import app
client = TestClient(app)
def test_healthcheck():
r = client.get("/health")
assert r.status_code == 200
ทดสอบสิ่งที่ผู้ใช้และระบบอื่นต้องพึ่งพา:
ใช้ข้อมูลที่คาดเดาได้ แยกบริการภายนอก (mock หรือใช้ test DB) และหลีกเลี่ยงสถานะร่วมระหว่างเทสต์ เทสต์ที่เร็วจะถูกรันบ่อยกว่า
การนำแอป FastAPI ขึ้นออนไลน์เกี่ยวกับการเลือก “runner” ที่เหมาะสมและเพิ่มสิ่งจำเป็นสำหรับ production
เมื่อคุณรัน uvicorn main:app --reload ในเครื่อง นั่นคือการตั้งค่าแบบพัฒนา: auto-reload ข้อผิดพลาดแสดงละเอียด และการตั้งค่าเพื่อความสะดวก
ใน production มักรัน Uvicorn แบบไม่มี reload บ่อยครั้งอยู่หลัง process manager (เช่น Gunicorn กับ Uvicorn workers) หรือตั้งอยู่หลัง reverse proxy เป้าหมายคือความเสถียร: รีสตาร์ทควบคุมได้, ประสิทธิภาพทำนายได้, และค่าเริ่มต้นที่ปลอดภัยกว่า
รูปแบบที่พบบ่อยคือ:
วิธีนี้ทำให้โค้ดชุดเดียว deploy ได้หลายสภาพแวดล้อมโดยไม่ต้องแก้ไฟล์
ก่อนเรียกว่าพร้อม ควรตรวจสอบว่ามี:
/health สำหรับการมอนิเตอร์และ load balancerเมื่อคุณย้ายจาก "ใช้งานบนเครื่อง" ไปสู่ "พร้อมส่ง" การทำให้การจัดการ API contract เป็นมาตรฐานช่วยได้ ทีมบางทีมใช้ OpenAPI ของ FastAPI ร่วมกับ workflow อัตโนมัติ — เช่น สร้างไคลเอนต์ อนุญาตให้ CI ตรวจสอบคำขอ และ deploy สม่ำเสมอ เครื่องมืออย่าง Koder.ai ก็สามารถช่วยในขั้นตอนนี้: คุณอธิบาย API ที่ต้องการผ่านการสนทนา ทดลอง endpoint และโมเดลอย่างรวดเร็ว แล้วส่งออกโค้ดต้นฉบับเพื่อรีวิวและ deploy ตามปกติ
FastAPI เป็นตัวเลือกที่ดีเมื่อคุณต้องการวิธีที่สะอาดและทันสมัยในการสร้าง REST API ใน Python — โดยเฉพาะเมื่อคุณใส่ใจเรื่องโมเดลการรับ/ส่งข้อมูลที่ชัดเจนและพฤติกรรมที่คาดเดาได้เมื่อระบบโต
FastAPI มักเด่นในสถานการณ์เหล่านี้:
FastAPI ไม่ใช่คำตอบที่ง่ายที่สุดเสมอไป:
FastAPI ทำงานได้เร็วในทางปฏิบัติ แต่ประสิทธิภาพขึ้นกับการเรียกฐานข้อมูล ความหน่วงเครือข่าย และตรรกะธุรกิจ คาดหวัง throughput และ latency ที่ดีสำหรับงาน API ทั่วไป — แต่อย่าไปคิดว่าเฟรมเวิร์คจะช่วยแก้ I/O ช้า หรือ query ที่ไม่เหมาะสมได้โดยลำพัง
ถ้า FastAPI ฟังดูเข้าท่า ให้เน้นที่รูปแบบ routing, โมเดล Pydantic, การเชื่อมฐานข้อมูล, background tasks และการพิสูจน์ตัวตนพื้นฐาน
เส้นทางที่ปฏิบัติได้คือ สร้างชุด endpoint เล็ก ๆ แล้วขยายด้วย dependencies ที่นำกลับใช้ได้และการทดสอบเมื่อ API โตขึ้น ถ้าคุณต้องการเร่งการตั้งค่าเริ่มแรก (routes, models, โครงสร้างพร้อม deploy) ให้พิจารณาเวิร์กโฟลว์แบบ vibe-coding — เช่น วางแผน endpoint ใน "planning mode" แล้ว iterate จากสเปคเดียว จุดนี้ Koder.ai อาจเป็นประโยชน์: คุณสามารถโปรโตไทป์แอปที่ขับเคลื่อนด้วย API จากการสนทนา แล้วปรับโค้ดที่สร้างขึ้นก่อนส่งออกไปรันในโปรเจกต์ปกติ
FastAPI เป็นเฟรมเวิร์คเว็บของ Python สำหรับสร้าง API โดยไม่ต้องเขียนโค้ดซ้ำมาก คุณเขียนฟังก์ชันสำหรับ endpoint (เช่น @app.get("/users")) แล้ว FastAPI จะจัดการ routing, การอ่านคำขอ, การตรวจสอบค่า และการตอบเป็น JSON ให้
ข้อได้เปรียบสำคัญคือ type hint และโมเดล Pydantic ของคุณทำหน้าที่เป็นสัญญาชัดเจนว่า API ยอมรับและคืนค่าอะไร
API คือชุด URL (endpoints) ที่ซอฟต์แวร์หนึ่งเรียกใช้เพื่อแลกเปลี่ยนข้อมูล
ตัวอย่าง: แอปพยากรณ์อากาศอาจร้องขอข้อมูลด้วย GET /weather?city=Berlin แล้วเซิร์ฟเวอร์ตอบด้วย JSON ที่มีข้อมูลเช่น อุณหภูมิและพยากรณ์ โดยที่แอปไม่ต้องเข้าถึงฐานข้อมูลโดยตรง — มันเพียงเรียก API แล้วแสดงผล
FastAPI ช่วยให้คุณสร้าง URL และการตอบเหล่านั้นด้วย Python ได้ง่ายขึ้น
Routing คือการจับคู่ HTTP method + path ไปยังฟังก์ชัน Python
ใน FastAPI มักใช้ decorator เช่น:
@app.get("/items") สำหรับการอ่านข้อมูล@app.post("/items") สำหรับการสร้าง@app.put("/items/{id}") สำหรับอัปเดต/แทนที่Path parameters เป็นส่วนหนึ่งของโครงสร้าง URL และมักใช้ระบุทรัพยากรเฉพาะ (จำเป็น)
GET /users/42 → 42 เป็น path parameterQuery parameters ถูกต่อหลัง ? และมักเป็นตัวกรองหรือค่าที่ไม่จำเป็น
โมเดล Pydantic กำหนดรูปร่างและกฎของข้อมูล (ชนิด ฟิลด์ที่ต้องมี ขอบเขต) FastAPI ใช้โมเดลเหล่านี้เพื่อ:
ถ้าการตรวจสอบล้มเหลว FastAPI มักตอบด้วย 422 Unprocessable Entity พร้อมรายละเอียดฟิลด์ที่ผิด
FastAPI สร้าง OpenAPI schema อัตโนมัติจาก endpoints, type hints และโมเดลของคุณ
คุณจะได้เอกสารแบบโต้ตอบโดยปริยาย:
/docs/redocเพราะ schema มาจากโค้ด เอกสารจึงอัปเดตตามเมื่อคุณเปลี่ยนพารามิเตอร์หรือโมเดล
ใช้ async def เมื่อ endpoint ของคุณใช้เวลารอ I/O (เช่น คำขอฐานข้อมูล, HTTP ขาออก, การอ่าน/เขียนไฟล์)
ใช้ def เมื่อ:
การผสม endpoint แบบ sync และ async ในแอปเดียวเป็นเรื่องปกติ
Dependency คือบล็อกที่นำกลับใช้ได้ ซึ่ง FastAPI จะฉีดให้กับ endpoint ผ่าน Depends()
มักใช้สำหรับ:
วิธีนี้ลดการทำซ้ำและรวมตรรกะข้ามจุดไว้ที่เดียว ทำให้แก้ไขง่ายขึ้นเมื่อระบบขยายตัว
FastAPI ไม่ได้ “เปิดความปลอดภัย” ให้โดยอัตโนมัติ — คุณต้องเลือกวิธีและนำไปใช้เอง
รูปแบบที่พบบ่อย:
X-API-Key)ข้อควรจำเพิ่มเติม:
สำหรับการทดสอบ คุณสามารถใช้ TestClient ของ FastAPI/Starlette เพื่อเรียก API ในกระบวนการเดียวกัน (ไม่ต้องสตาร์ทเซิร์ฟเวอร์)
ตัวอย่างโครงสร้างการทดสอบที่ควรมี:
การ deploy: รันบน ASGI server (เช่น Uvicorn) โดยเพิ่มองค์ประกอบสำหรับ production เช่น logging, health checks (เช่น ), timeout และการตั้งค่าตาม environment
@app.delete("/items/{id}")วิธีนี้ทำให้หน้าตาของ API อ่านได้ง่ายจากโค้ด
GET /users?limit=10&active=true → limit, active เป็น query parameters/health