ปลดล็อกพลังของการสร้างเอกสาร API อัตโนมัติของ FastAPI ด้วย OpenAPI schema เพื่อสร้างเอกสารที่แข็งแกร่ง โต้ตอบได้ และเข้าถึงได้ทั่วโลกอย่างง่ายดาย เรียนรู้แนวทางปฏิบัติที่ดีที่สุดในการปรับปรุง API Python ของคุณ
การสร้างเอกสาร API ระดับมืออาชีพด้วย Python FastAPI และ OpenAPI Schema
ในโลกของการพัฒนาซอฟต์แวร์ที่เปลี่ยนแปลงไปอย่างรวดเร็ว Application Programming Interfaces (APIs) ทำหน้าที่เป็นกระดูกสันหลังสำหรับระบบที่เชื่อมโยงกัน ช่วยอำนวยความสะดวกในการสื่อสารระหว่างบริการและแอปพลิเคชันที่แตกต่างกัน เพื่อให้ API มีประสิทธิภาพและเป็นที่ยอมรับในวงกว้าง จะต้องสามารถค้นหา เข้าใจ และใช้งานได้ง่าย นี่คือจุดที่เอกสาร API ที่ครอบคลุม ถูกต้อง และเป็นปัจจุบัน ไม่ใช่แค่ความสะดวกสบาย แต่เป็นสิ่งจำเป็นอย่างยิ่ง สำหรับทีมพัฒนาทั่วโลกและฐานผู้บริโภคที่หลากหลาย เอกสารที่ดีเยี่ยมจะช่วยเชื่อมช่องว่างทางภูมิศาสตร์และเทคนิค เปลี่ยนอินเทอร์เฟซที่ซับซ้อนให้เป็นเครื่องมือที่เข้าถึงได้
เฟรมเวิร์ก FastAPI ของ Python โดดเด่นในฐานะเฟรมเวิร์กเว็บสมัยใหม่ที่มีประสิทธิภาพสูง ออกแบบมาสำหรับการสร้าง API ด้วย Python 3.8+ โดยอิงจาก Python type hints มาตรฐาน หนึ่งในคุณสมบัติที่น่าสนใจที่สุดคือความสามารถที่ไม่มีใครเทียบได้ในการสร้างเอกสาร API แบบโต้ตอบโดยอัตโนมัติ โดยอิงจาก OpenAPI Specification (OAS) ความสามารถนี้ช่วยปรับปรุงขั้นตอนการทำงานของการพัฒนา ลดความพยายามด้วยตนเอง และรับรองว่าเอกสารของคุณจะซิงโครไนซ์กับโค้ดเบสของคุณอยู่เสมอ คู่มือฉบับสมบูรณ์นี้จะเจาะลึกว่า FastAPI ใช้ประโยชน์จาก OpenAPI เพื่อสร้างเอกสาร API ระดับแนวหน้าได้อย่างไร สำรวจแนวทางปฏิบัติที่ดีที่สุดในการปรับปรุงกระบวนการนี้ และอภิปรายถึงผลกระทบอย่างลึกซึ้งที่มีต่อประสบการณ์ของนักพัฒนาทั่วโลก
ความจำเป็นของเอกสาร API ที่ยอดเยี่ยม
ก่อนที่จะเจาะลึกกลไกของ FastAPI และ OpenAPI สิ่งสำคัญคือต้องเข้าใจว่าทำไมเอกสาร API ที่เหนือกว่าจึงเป็นสินทรัพย์ที่ไม่สามารถต่อรองได้ในระบบนิเวศเทคโนโลยีระดับโลกในปัจจุบัน
ทำไมเอกสารจึงเป็นสิ่งที่ขาดไม่ได้
- การเริ่มต้นทำงานของนักพัฒนาที่เร็วขึ้น: นักพัฒนาใหม่ ไม่ว่าจะเข้าร่วมทีมภายในหรือรวมบริการจากภายนอก ต่างพึ่งพาเอกสารอย่างมากเพื่อทำความเข้าใจวิธีการใช้ API เอกสารที่ชัดเจนช่วยลดช่วงการเรียนรู้อย่างมาก ทำให้นักพัฒนาสามารถทำงานได้อย่างรวดเร็วขึ้น ไม่ว่าจะอยู่ที่ใดหรือคุ้นเคยกับระบบมากน้อยเพียงใด
- ลดความยุ่งยากและภาระการสนับสนุน: เมื่อผู้ใช้ API เข้าถึงคำตอบได้ง่าย พวกเขามีโอกาสน้อยที่จะพบปัญหาหรือต้องการการสนับสนุนโดยตรง เอกสารที่เขียนดีทำหน้าที่เป็นพอร์ทัลสนับสนุนตนเอง ช่วยปลดปล่อยทรัพยากรด้านวิศวกรรมที่มีค่า สิ่งนี้เป็นประโยชน์อย่างยิ่งสำหรับการดำเนินงานทั่วโลกที่ความแตกต่างของเขตเวลาอาจทำให้การสื่อสารแบบซิงโครนัสซับซ้อนขึ้น
- การเพิ่มการนำไปใช้และการมีส่วนร่วมของ API: API ที่มีเอกสารดีจะดึงดูดผู้ใช้ที่มีศักยภาพมากขึ้น ตัวอย่างที่ครอบคลุม คำอธิบายที่ชัดเจน และอินเทอร์เฟซแบบโต้ตอบเชิญชวนให้ทดลองและส่งเสริมการรวมที่ลึกซึ้งยิ่งขึ้น นำไปสู่การนำไปใช้ในวงกว้างขึ้นและระบบนิเวศที่เฟื่องฟูรอบ API ของคุณ
- อำนวยความสะดวกในการทำงานร่วมกันทั่วโลก: ในโลกของทีมงานที่กระจายตัวและบริษัทข้ามชาติ เอกสารทำหน้าที่เป็นภาษากลาง มันทำให้มั่นใจว่านักพัฒนาจากภูมิหลังทางวัฒนธรรมและภาษาที่แตกต่างกันสามารถเข้าใจและมีส่วนร่วมในโครงการ API เดียวกันได้อย่างมีประสิทธิภาพ
- การบำรุงรักษาและอายุการใช้งานที่ยาวนานขึ้น: เอกสารที่ดีช่วยในการบำรุงรักษา API ในระยะยาว ช่วยให้นักพัฒนาในอนาคตเข้าใจการตัดสินใจในการออกแบบ การทำงานภายใน และข้อจำกัดที่อาจเกิดขึ้น แม้จะผ่านไปหลายปีหลังจากการพัฒนาเริ่มต้น ซึ่งเป็นการขยายอายุการใช้งานที่เป็นประโยชน์ของ API
- การปฏิบัติตามข้อกำหนดและการกำกับดูแล: สำหรับบางอุตสาหกรรมและสภาพแวดล้อมด้านกฎระเบียบ เอกสาร API โดยละเอียดอาจเป็นข้อกำหนดสำหรับการปฏิบัติตาม ให้บันทึกที่ตรวจสอบได้ของฟังก์ชัน API และการจัดการข้อมูล
ความท้าทายของเอกสารที่ทำด้วยมือ
ในอดีต เอกสาร API มักเป็นกระบวนการที่ทำด้วยมืออย่างละเอียดถี่ถ้วน ซึ่งเต็มไปด้วยความท้าทาย:
- ข้อมูลที่ล้าสมัย: เมื่อ API พัฒนาขึ้น เอกสารที่ทำด้วยมือมักจะล้าหลัง ทำให้เกิดความคลาดเคลื่อนระหว่างเอกสารกับพฤติกรรม API จริง สิ่งนี้ทำให้นักพัฒ้ารู้สึกหงุดหงิดและบั่นทอนความไว้วางใจ
- ความไม่สอดคล้องกัน: ผู้เขียนที่แตกต่างกัน รูปแบบการเขียนที่หลากหลาย และการขาดรูปแบบมาตรฐานอาจนำไปสู่เอกสารที่ไม่สอดคล้องกัน ทำให้ผู้ใช้สำรวจและทำความเข้าใจได้ยากขึ้น
- ใช้เวลามากและใช้ทรัพยากรสูง: การเขียนและบำรุงรักษาเอกสารด้วยมือใช้เวลาและความพยายามอย่างมาก ทำให้ต้องหันเหทรัพยากรออกจากงานพัฒนาหลัก
- มีข้อผิดพลาดได้ง่าย: ข้อผิดพลาดของมนุษย์ในเอกสารที่ทำด้วยมือสามารถนำไปสู่ความไม่ถูกต้องที่ทำให้เกิดปัญหาในการรวมระบบและสิ้นเปลืองเวลาในการพัฒนาสำหรับผู้บริโภค
FastAPI ด้วยการรวมเข้ากับ OpenAPI Specification อย่างลึกซึ้ง ช่วยแก้ปัญหาเหล่านี้ได้อย่างสง่างามโดยการทำให้กระบวนการสร้างเอกสารเป็นไปโดยอัตโนมัติ ทำให้มั่นใจถึงความถูกต้อง ความสอดคล้อง และความเป็นปัจจุบันโดยใช้ความพยายามน้อยที่สุด
ขอแนะนำ FastAPI: เฟรมเวิร์กเว็บ Python สมัยใหม่
FastAPI เป็นเฟรมเวิร์กเว็บ Python ที่ค่อนข้างใหม่ แต่ทรงพลังอย่างไม่น่าเชื่อ ซึ่งได้รับความนิยมอย่างรวดเร็วเนื่องจากประสิทธิภาพที่ยอดเยี่ยมและคุณสมบัติที่เป็นมิตรกับนักพัฒนา สร้างขึ้นบน Starlette สำหรับส่วนเว็บและ Pydantic สำหรับส่วนข้อมูล FastAPI มีคุณสมบัติดังนี้:
- ประสิทธิภาพสูง: เทียบเท่ากับ NodeJS และ Go ต้องขอบคุณ Starlette
- เขียนโค้ดได้รวดเร็ว: เพิ่มความเร็วในการพัฒนา 200% ถึง 300%
- ข้อผิดพลาดน้อยลง: ลดข้อผิดพลาดของมนุษย์ลง 40% เนื่องจากมี type hints ที่แข็งแกร่ง
- ใช้งานง่าย: รองรับโปรแกรมแก้ไขที่ดีเยี่ยม, มีการเติมข้อความอัตโนมัติทุกที่, ใช้เวลาในการดีบักน้อยลง
- แข็งแกร่ง: ได้โค้ดพร้อมใช้งานจริงพร้อมเอกสารแบบโต้ตอบอัตโนมัติ
- อิงตามมาตรฐาน: อิงตาม (และเข้ากันได้เต็มที่กับ) มาตรฐานเปิด เช่น OpenAPI และ JSON Schema
รากฐานของมันบนมาตรฐานสมัยใหม่เช่น OpenAPI และ JSON Schema เป็นสิ่งที่ทำให้เป็นตัวเลือกที่ไม่มีใครเทียบได้สำหรับการพัฒนา API ที่เอกสารเป็นข้อกังวลหลัก มันใช้ Python type hints เพื่อประกาศรูปร่างของข้อมูล ซึ่ง Pydantic จะใช้สำหรับการตรวจสอบข้อมูล, การทำให้เป็นอนุกรม และที่สำคัญที่สุดสำหรับการสร้าง OpenAPI schema
ทำความเข้าใจ OpenAPI: ภาษาสากลสำหรับ API
เพื่อให้เข้าใจถึงความสามารถในการสร้างเอกสารของ FastAPI อย่างถ่องแท้ เราต้องทำความเข้าใจ OpenAPI Specification ก่อน
OpenAPI คืออะไร?
OpenAPI Specification (OAS) คือภาษาคำอธิบายอินเทอร์เฟซสำหรับ RESTful API ที่เป็นกลางต่อภาษา เป็นมาตรฐาน และเครื่องจักรสามารถอ่านได้ ช่วยให้ทั้งมนุษย์และคอมพิวเตอร์สามารถค้นพบและทำความเข้าใจความสามารถของบริการได้โดยไม่ต้องเข้าถึงซอร์สโค้ด เอกสารประกอบ หรือการตรวจสอบทราฟฟิกเครือข่าย เดิมเรียกว่า Swagger Specification ซึ่งถูกบริจาคให้กับ Linux Foundation ในปี 2015 และเปลี่ยนชื่อเป็น OpenAPI ตั้งแต่นั้นมาก็กลายเป็นมาตรฐานโดยพฤตินัยสำหรับการอธิบาย API สมัยใหม่
พลังของการอธิบาย API ที่เป็นมาตรฐาน
เอกสาร OpenAPI (มักอยู่ในรูปแบบ JSON หรือ YAML) ทำหน้าที่เป็นสัญญาสำหรับ API ของคุณ สัญญานี้ให้ประโยชน์มากมาย:
- เครื่องจักรสามารถอ่านได้: เนื่องจากเป็นรูปแบบที่มีโครงสร้าง เครื่องมือจึงสามารถแยกวิเคราะห์และทำความเข้าใจโครงสร้างของ API, จุดสิ้นสุด, พารามิเตอร์ และการตอบกลับได้
- อินเทอร์เฟซเอกสารแบบโต้ตอบ: เครื่องมืออย่าง Swagger UI และ ReDoc สามารถใช้เอกสาร OpenAPI เพื่อสร้างพอร์ทัลเอกสารที่สวยงาม โต้ตอบได้ และสำรวจได้โดยอัตโนมัติ
- การสร้างโค้ดไคลเอ็นต์: OpenAPI Generator สามารถสร้างไลบรารีไคลเอ็นต์ API (SDKs) ได้โดยอัตโนมัติในภาษาโปรแกรมหลายสิบภาษา ช่วยเร่งการรวมระบบสำหรับนักพัฒนาทั่วโลกได้อย่างมาก
- การทดสอบอัตโนมัติ: เฟรมเวิร์กการทดสอบสามารถใช้ OpenAPI spec เพื่อตรวจสอบการตอบกลับของ API เทียบกับ schema ที่กำหนด เพื่อให้มั่นใจถึงความสอดคล้องและความถูกต้อง
- การวิเคราะห์ความปลอดภัย: เครื่องมือความปลอดภัยสามารถวิเคราะห์คำจำกัดความของ API เพื่อหาช่องโหว่ที่อาจเกิดขึ้นหรือการปฏิบัติตามนโยบายความปลอดภัย
- ประสบการณ์นักพัฒนาแบบครบวงจร: โดยไม่คำนึงถึงเทคโนโลยีพื้นฐาน API ที่อธิบายด้วย OpenAPI จะนำเสนออินเทอร์เฟซที่สอดคล้องกันแก่ผู้บริโภค ซึ่งส่งเสริมประสบการณ์การรวมระบบที่ราบรื่นยิ่งขึ้น
ส่วนประกอบหลักของเอกสาร OpenAPI
เอกสาร OpenAPI มักจะอธิบายลักษณะต่อไปนี้ของ API:
- Info: เมตาดาต้า API ทั่วไป เช่น ชื่อ, คำอธิบาย, เวอร์ชัน, ข้อกำหนดในการให้บริการ, ข้อมูลติดต่อ และใบอนุญาต
- Servers: URL พื้นฐานสำหรับ API (เช่น สภาพแวดล้อมการพัฒนา, staging, production)
- Paths: จุดสิ้นสุดแต่ละรายการ (เช่น
/users,/items/{item_id}) และวิธีการ HTTP ที่รองรับ (GET, POST, PUT, DELETE เป็นต้น) - Components: คำจำกัดความที่นำกลับมาใช้ใหม่ได้สำหรับ data schemas (โดยใช้ JSON Schema), request bodies, parameters, headers, security schemes และ responses สิ่งนี้ส่งเสริมความสอดคล้องและลดความซ้ำซ้อน
- Tags: หมวดหมู่ที่ใช้จัดกลุ่มการทำงานของ path ที่เกี่ยวข้องเพื่อการจัดระเบียบที่ดีขึ้นใน UI ของเอกสาร
การรวม FastAPI เข้ากับ OpenAPI อย่างราบรื่น
ความมหัศจรรย์ที่แท้จริงของ FastAPI อยู่ที่การสร้าง OpenAPI schema โดยอัตโนมัติและราบรื่น เมื่อคุณกำหนดจุดสิ้นสุด API, โมเดลข้อมูล และโครงสร้างคำขอ/การตอบกลับโดยใช้ Python type hints มาตรฐานและ Pydantic, FastAPI จะอนุมานข้อมูลที่จำเป็นทั้งหมดอย่างชาญฉลาดเพื่อสร้างเอกสาร OpenAPI ที่สมบูรณ์ ซึ่งหมายความว่า:
- ไม่ต้องเขียน OpenAPI ด้วยตนเอง: คุณเขียนโค้ด Python ของคุณ และ FastAPI จะจัดการงานที่ซับซ้อนในการสร้าง OpenAPI specification ที่เครื่องจักรสามารถอ่านได้
- เอกสารที่เป็นปัจจุบันอยู่เสมอ: เนื่องจากเอกสารมาจากโค้ดของคุณโดยตรง การเปลี่ยนแปลงใดๆ กับจุดสิ้นสุด, พารามิเตอร์ หรือโมเดลของ API จะสะท้อนทันทีใน OpenAPI schema และด้วยเหตุนี้ในเอกสารแบบโต้ตอบ สิ่งนี้ช่วยขจัดปัญหาทั่วไปของเอกสารที่ล้าสมัย
- ความสอดคล้องโดยการออกแบบ: การตรวจสอบข้อมูลและการทำให้เป็นอนุกรมที่ Pydantic จัดหาให้ จะแจ้งคำจำกัดความ JSON Schema ภายใน OpenAPI โดยตรง ทำให้มั่นใจว่าความคาดหวังของ API ของคุณได้รับการบันทึกและบังคับใช้อย่างสอดคล้อง
เริ่มต้นใช้งาน: แอปพลิเคชัน FastAPI ตัวแรกของคุณพร้อมเอกสารอัตโนมัติ
มาลองสร้างแอปพลิเคชัน FastAPI อย่างง่าย และดูการสร้างเอกสารอัตโนมัติในการทำงาน
การตั้งค่าสภาพแวดล้อมของคุณ
ขั้นแรก ตรวจสอบให้แน่ใจว่าคุณได้ติดตั้ง Python 3.8+ แล้ว จากนั้น ติดตั้ง FastAPI และ Uvicorn (เซิร์ฟเวอร์ ASGI เพื่อรันแอปพลิเคชันของคุณ):
pip install fastapi "uvicorn[standard]"
จุดสิ้นสุด FastAPI อย่างง่าย
สร้างไฟล์ชื่อ main.py พร้อมเนื้อหาดังนี้:
from fastapi import FastAPI
from typing import Optional
from pydantic import BaseModel
app = FastAPI(
title="Global Item Management API",
description="A simple API to manage items for diverse international users.",
version="1.0.0",
contact={
"name": "API Support Team",
"url": "https://example.com/contact",
"email": "support@example.com",
},
license_info={
"name": "MIT License",
"url": "https://opensource.org/licenses/MIT",
},
)
class Item(BaseModel):
name: str
description: Optional[str] = None
price: float
tax: Optional[float] = None
@app.get("/")
async def read_root():
"""
Provides a welcome message for the API.
"""
return {"message": "Welcome to the Global Item Management API!"}
@app.get("/items/{item_id}", response_model=Item)
async def read_item(item_id: int, q: Optional[str] = None):
"""
Retrieve details for a specific item by its unique ID.
- <b>item_id</b>: The ID of the item to retrieve.
- <b>q</b>: An optional query string for filtering or searching.
"""
item_data = {"name": "Example Item", "price": 12.5}
if q:
item_data["description"] = f"A wonderful {item_data['name']} related to '{q}'."
else:
item_data["description"] = "A standard item available globally."
return item_data
@app.post("/items/", response_model=Item)
async def create_item(item: Item):
"""
Create a new item in the system.
This endpoint accepts an Item object in the request body
and returns the created item's details.
"""
# In a real application, you'd save this to a database
print(f"Received item: {item.dict()}")
return item
รันแอปพลิเคชันของคุณโดยใช้ Uvicorn จากเทอร์มินัลของคุณ:
uvicorn main:app --reload
คุณควรเห็นเอาต์พุตที่ระบุว่าเซิร์ฟเวอร์กำลังทำงาน โดยปกติจะอยู่ที่ http://127.0.0.1:8000
สำรวจเอกสารอัตโนมัติ (Swagger UI & ReDoc)
ตอนนี้ เปิดเว็บเบราว์เซอร์ของคุณและไปยัง URL เหล่านี้:
- เอกสารแบบโต้ตอบ (Swagger UI):
http://127.0.0.1:8000/docs - เอกสารทางเลือก (ReDoc):
http://127.0.0.1:8000/redoc - Raw OpenAPI JSON:
http://127.0.0.1:8000/openapi.json
ที่ /docs คุณจะพบกับ Swagger UI ซึ่งเป็นอินเทอร์เฟซเว็บที่ใช้งานง่ายและโต้ตอบได้ ซึ่งจะแสดงเอกสาร API ของคุณโดยอัตโนมัติโดยอิงจาก OpenAPI schema ที่สร้างโดย FastAPI คุณจะเห็น:
- ชื่อ API, คำอธิบาย, เวอร์ชัน, ข้อมูลติดต่อ และข้อมูลใบอนุญาตที่คุณกำหนดไว้
- รายการจุดสิ้นสุด API ทั้งหมดของคุณ (
/,/items/{item_id},/items/) - สำหรับแต่ละจุดสิ้นสุด, วิธีการ HTTP (GET, POST), สรุป และคำอธิบายโดยละเอียด (มาจาก docstrings ของฟังก์ชันของคุณ)
- พารามิเตอร์อินพุต (path, query, body) พร้อมประเภท, คำอธิบาย และว่าจำเป็นหรือไม่
- Response schemas แสดงโครงสร้างที่คาดหวังของข้อมูลที่ API ส่งคืน
- ที่สำคัญ คุณสามารถคลิก "Try it out" และ "Execute" เพื่อทำการเรียก API จริงได้โดยตรงจากอินเทอร์เฟซเอกสาร ซึ่งเป็น Sandbox ที่ทรงพลังสำหรับนักพัฒนา
ที่ /redoc คุณจะพบการนำเสนอเอกสารทางเลือก ซึ่งมักเป็นที่นิยมสำหรับเลย์เอาต์ที่สะอาดตาแบบหน้าเดียวและอ่านง่าย UI ทั้งสองนี้จัดหาให้โดย FastAPI โดยอัตโนมัติโดยไม่ต้องมีการกำหนดค่าเพิ่มเติมจากคุณ
จุดสิ้นสุด /openapi.json ให้บริการไฟล์ JSON ดิบที่อธิบาย API ทั้งหมดของคุณตาม OpenAPI Specification ไฟล์นี้คือสิ่งที่ Swagger UI และ ReDoc ใช้ และยังเป็นไฟล์ที่เครื่องมืออื่นๆ (เช่น OpenAPI Generator สำหรับ client SDKs) จะใช้ด้วย
การปรับปรุง OpenAPI Schema ของคุณ: นอกเหนือจากพื้นฐาน
แม้ว่าค่าเริ่มต้นของ FastAPI จะยอดเยี่ยม แต่คุณอาจพบสถานการณ์ที่ต้องควบคุมการสร้างเอกสารหรือการนำเสนอมากขึ้น
การเพิ่มเมตาดาต้าเพื่อความชัดเจน
เมื่อเริ่มต้นแอปพลิเคชัน FastAPI คุณสามารถส่งพารามิเตอร์หลายตัวเพื่อเสริมเอกสาร API โดยรวม สิ่งนี้มีความสำคัญอย่างยิ่งในการให้บริบทแก่นักพัฒนาทั่วโลกเกี่ยวกับวัตถุประสงค์ของ API และช่องทางการสนับสนุนของคุณ
from fastapi import FastAPI
app = FastAPI(
title="Global Financial Services API",
description="This API provides real-time financial data and transaction processing for international clients.",
version="2.1.0",
terms_of_service="https://example.com/terms/",
contact={
"name": "Global API Support",
"url": "https://example.com/contact/",
"email": "api-support@example.com",
},
license_info={
"name": "Proprietary License",
"url": "https://example.com/license/",
},
# You can also specify the openapi_url if you want to change the default /openapi.json
# openapi_url="/v2/openapi.json"
)
@app.get("/status")
async def get_status():
"""Checks the operational status of the API."""
return {"status": "Operational", "uptime": "99.9%"}
พารามิเตอร์เหล่านี้จะเติมข้อมูลวัตถุ "Info" ใน OpenAPI schema ของคุณ ทำให้พอร์ทัลเอกสารของคุณมีข้อมูลมากขึ้นและเป็นมืออาชีพ
การอธิบาย Path Operations ด้วย `summary` และ `description`
ทุกการทำงานของ path (เช่น `@app.get`, `@app.post`) สามารถมี `summary` และ `description` เพื่อให้วัตถุประสงค์ชัดเจนในเอกสาร FastAPI ใช้ docstring ของฟังก์ชันสำหรับ `description` โดยค่าเริ่มต้น แต่คุณสามารถกำหนดสิ่งเหล่านี้ได้อย่างชัดเจน
from fastapi import FastAPI, Path, Query
from typing import Optional
app = FastAPI()
@app.get(
"/products/{product_id}",
summary="Retrieve details of a specific product",
description="This endpoint fetches comprehensive information about a product, including its name, price, and availability across different regions. Use a numeric product_id.",
)
async def get_product(
product_id: int = Path(..., description="The unique identifier of the product to retrieve", ge=1),
region: Optional[str] = Query(
None,
description="Optional: Filter product availability by region (e.g., 'EMEA', 'APAC', 'AMERICAS').",
example="EMEA"
)
):
"""
Fetches product details from the database.
If a region is provided, it can filter regional data.
"""
# ... logic to fetch product ...
return {"product_id": product_id, "name": "Global Gadget", "price": 99.99, "region": region}
Docstring ถูกใช้เป็น `description` โดยค่าเริ่มต้น แต่ `summary` สามารถส่งเป็นอาร์กิวเมนต์โดยตรงไปยังตัวตกแต่ง path การใช้ทั้งสองอย่างช่วยปรับปรุงความสามารถในการอ่านใน Swagger UI และ ReDoc
การจัดกลุ่มจุดสิ้นสุดด้วย Tags
สำหรับ API ที่มีขนาดใหญ่ขึ้นซึ่งมีจุดสิ้นสุดจำนวนมาก การจัดระเบียบเป็นกลุ่มเชิงตรรกะ (tags) ช่วยปรับปรุงการนำทางได้อย่างมาก คุณสามารถกำหนด tags และคำอธิบายได้โดยตรงในอินสแตนซ์แอปพลิเคชัน FastAPI ของคุณ จากนั้นกำหนดให้กับ path operations แต่ละรายการ
from fastapi import FastAPI, Depends, HTTPException, status
from typing import List, Dict
# Define tags with metadata for better organization
tags_metadata = [
{
"name": "users",
"description": "Operations with users. Manage user profiles and authentication.",
},
{
"name": "items",
"description": "Manage items in the inventory. CRUD operations for products.",
},
{
"name": "admin",
"description": "<b>Admin-level operations</b> requiring elevated privileges. Handle system configurations.",
"externalDocs": {
"description": "Admin documentation",
"url": "https://example.com/admin_docs",
},
},
]
app = FastAPI(openapi_tags=tags_metadata)
async def get_current_user():
# Placeholder for a real authentication dependency
return {"username": "admin_user", "roles": ["admin"]}
@app.get("/users/", tags=["users"])
async def read_users():
return [{"username": "Alice"}, {"username": "Bob"}]
@app.post("/items/", tags=["items"])
async def create_item():
return {"message": "Item created"}
@app.delete("/admin/clear-cache", tags=["admin"])
async def clear_cache(current_user: Dict = Depends(get_current_user)):
if "admin" not in current_user["roles"]:
raise HTTPException(status_code=status.HTTP_403_FORBIDDEN, detail="Not authorized")
return {"message": "Cache cleared by admin"}
ในเอกสารแบบโต้ตอบ tags เหล่านี้จะปรากฏเป็นส่วนที่ขยายได้ ทำให้ผู้ใช้ค้นหาการเรียก API ที่เกี่ยวข้องได้ง่ายขึ้น
การสร้างแบบจำลองข้อมูลที่แข็งแกร่งด้วย Pydantic
โมเดล Pydantic เป็นพื้นฐานของ FastAPI พวกมันให้การตรวจสอบข้อมูลและการทำให้เป็นอนุกรม และที่สำคัญ พวกมันจะถูกแปลงเป็นคำจำกัดความ JSON Schema โดยอัตโนมัติภายในเอกสาร OpenAPI ของคุณ สิ่งนี้ทำให้มั่นใจว่าเอกสารจะสะท้อนโครงสร้างที่คาดหวังของ request bodies และ response models ของ API ของคุณได้อย่างถูกต้อง
from fastapi import FastAPI
from pydantic import BaseModel, Field
from typing import Optional, List
from datetime import datetime
app = FastAPI()
class Location(BaseModel):
city: str = Field(..., description="The city name of the location.")
country: str = Field(..., description="The country name, e.g., 'Germany', 'Japan', 'Brazil'.")
latitude: float = Field(..., description="Geographical latitude.", ge=-90, le=90)
longitude: float = Field(..., description="Geographical longitude.", ge=-180, le=180)
class SensorData(BaseModel):
sensor_id: str = Field(..., example="sensor-001-eu", description="Unique identifier for the sensor. Must be non-empty.")
timestamp: datetime = Field(..., description="Timestamp of the data reading in ISO 8601 format.")
temperature_celsius: float = Field(..., description="Temperature reading in Celsius.", ge=-273.15)
humidity_percent: Optional[float] = Field(None, description="Relative humidity in percent.", ge=0, le=100)
location: Location = Field(..., description="Geographical location where the sensor data was recorded.")
@app.post("/sensors/data", response_model=SensorData, summary="Submit new sensor data")
async def receive_sensor_data(data: SensorData):
"""
Accepts sensor data from various global monitoring stations.
The data includes a unique sensor ID, timestamp, temperature,
optional humidity, and location details.
"""
print(f"Received sensor data: {data.json()}")
# In a real application, this data would be stored or processed
return data
@app.get("/sensors/latest/{sensor_id}", response_model=SensorData, summary="Get latest data for a sensor")
async def get_latest_sensor_data(
sensor_id: str = Path(..., description="The ID of the sensor to retrieve data for.", min_length=5)
):
"""
Retrieves the most recent data point for a specified sensor.
"""
# Simulate fetching latest data
mock_data = SensorData(
sensor_id=sensor_id,
timestamp=datetime.now(),
temperature_celsius=25.5,
humidity_percent=60.0,
location=Location(city="Tokyo", country="Japan", latitude=35.6895, longitude=139.6917)
)
return mock_data
ในตัวอย่างนี้ ใช้โมเดล Pydantic `SensorData` และ `Location` โปรดสังเกตว่า `Field` ถูกใช้เพื่อเพิ่มคำอธิบาย ตัวอย่าง และกฎการตรวจสอบ (`ge`, `le`, `min_length`) โดยตรงไปยังฟิลด์ของโมเดล รายละเอียดเหล่านี้จะถูกแปลเป็น OpenAPI schema โดยอัตโนมัติ ซึ่งให้เอกสารที่สมบูรณ์และแม่นยำอย่างเหลือเชื่อสำหรับโครงสร้างข้อมูลของ API ของคุณ
การทำเอกสาร Response
นอกเหนือจากการตอบกลับที่สำเร็จหลัก API มักจะมีการตอบกลับข้อผิดพลาดต่างๆ FastAPI ช่วยให้คุณสามารถทำเอกสารสิ่งเหล่านี้ได้อย่างชัดเจนโดยใช้พารามิเตอร์ `responses` ใน path operations ของคุณ สิ่งนี้จะแจ้งให้ผู้ใช้ API ทราบถึงผลลัพธ์ที่เป็นไปได้ทั้งหมด ซึ่งสำคัญสำหรับการจัดการข้อผิดพลาดที่แข็งแกร่ง
from fastapi import FastAPI, HTTPException, status
from pydantic import BaseModel, Field
from typing import Dict
app = FastAPI()
class ErrorDetail(BaseModel):
message: str = Field(..., description="A human-readable message explaining the error.")
code: str = Field(..., description="An internal error code for programmatic identification.")
class User(BaseModel):
user_id: str = Field(..., example="user-gb-123", description="Unique identifier for the user.")
name: str
email: str
# Simulate a user database
fake_users_db = {
"user-gb-123": {"name": "John Doe", "email": "john.doe@example.com"},
"user-fr-456": {"name": "Jeanne Dupont", "email": "jeanne.dupont@example.com"},
}
@app.get(
"/users/{user_id}",
response_model=User,
responses={
status.HTTP_404_NOT_FOUND: {
"model": ErrorDetail,
"description": "The user was not found.",
"content": {
"application/json": {
"example": {"message": "User with ID 'user-gb-999' not found.", "code": "USER_NOT_FOUND"}
}
}
},
status.HTTP_400_BAD_REQUEST: {
"model": ErrorDetail,
"description": "Invalid user ID format.",
"content": {
"application/json": {
"example": {"message": "Invalid user ID format. Must start with 'user-'.", "code": "INVALID_ID_FORMAT"}
}
}
},
status.HTTP_500_INTERNAL_SERVER_ERROR: {
"model": ErrorDetail,
"description": "Internal server error.",
"content": {
"application/json": {
"example": {"message": "An unexpected error occurred.", "code": "INTERNAL_SERVER_ERROR"}
}
}
}
},
summary="Get user details by ID"
)
async def get_user(user_id: str):
"""
Retrieves detailed information for a specific user.
Raises:
HTTPException 400: If the user ID format is invalid.
HTTPException 404: If the user is not found.
"""
if not user_id.startswith("user-"):
raise HTTPException(
status_code=status.HTTP_400_BAD_REQUEST,
detail={"message": "Invalid user ID format. Must start with 'user-'.", "code": "INVALID_ID_FORMAT"}
)
user_data = fake_users_db.get(user_id)
if not user_data:
raise HTTPException(
status_code=status.HTTP_404_NOT_FOUND,
detail={"message": f"User with ID '{user_id}' not found.", "code": "USER_NOT_FOUND"}
)
return User(user_id=user_id, **user_data)
ที่นี่ เรากำหนดโมเดล Pydantic `ErrorDetail` สำหรับการตอบกลับข้อผิดพลาดที่สอดคล้องกัน พจนานุกรม `responses` แมปโค้ดสถานะ HTTP กับคำอธิบายโดยละเอียด รวมถึงโมเดล Pydantic ที่แสดงถึงเนื้อหาข้อผิดพลาด และแม้แต่ตัวอย่างเพย์โหลด รายละเอียดระดับนี้ช่วยให้นักพัฒนาไคลเอ็นต์สามารถจัดการผลลัพธ์ API ต่างๆ ได้อย่างสง่างาม ซึ่งสำคัญสำหรับการสร้างแอปพลิเคชันทั่วโลกที่ยืดหยุ่น
การรักษาความปลอดภัย API และการทำเอกสารการรับรองความถูกต้อง
ความปลอดภัยของ API เป็นสิ่งสำคัญยิ่ง FastAPI ทำให้ง่ายต่อการกำหนดและจัดทำเอกสารโครงการรักษาความปลอดภัย (เช่น OAuth2, API Keys, HTTP Basic Auth) ซึ่งจะสะท้อนอยู่ในเอกสาร OpenAPI ของคุณ ทำให้นักพัฒนาเข้าใจวิธีการยืนยันตัวตนกับ API ของคุณ
from fastapi import FastAPI, Depends, HTTPException, status
from fastapi.security import OAuth2PasswordBearer
from pydantic import BaseModel, Field
from typing import Dict
# Define OAuth2 bearer scheme
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")
# Placeholder for user management (in a real app, this would be from a database)
class UserInDB(BaseModel):
username: str
hashed_password: str
full_name: Optional[str] = None
email: Optional[str] = None
disabled: Optional[bool] = None
def get_user_from_db(username: str):
# Simulate a database lookup
users_db = {
"admin@example.com": UserInDB(
username="admin@example.com",
hashed_password="fakehashedpassword", # In real app, hash this!
full_name="Admin User",
email="admin@example.com"
)
}
return users_db.get(username)
async def get_current_user(token: str = Depends(oauth2_scheme)):
# In a real app, you'd decode the JWT token, validate it, and fetch the user
# For this example, we'll just check if it's a known token or return a dummy user
if token == "secure-token-123":
return get_user_from_db("admin@example.com")
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="Invalid authentication credentials",
headers={"WWW-Authenticate": "Bearer"},
)
app = FastAPI(
title="Secure Global API",
description="An API demonstrating OAuth2 authentication for sensitive endpoints.",
version="1.0.0"
)
@app.get("/items/secure/", tags=["items"], summary="Retrieve all secure items (requires authentication)")
async def read_secure_items(current_user: UserInDB = Depends(get_current_user)):
"""
Fetches a list of items that are only accessible to authenticated users.
"""
return [
{"item_id": "secure-item-001", "owner": current_user.username},
{"item_id": "secure-item-002", "owner": current_user.username}
]
@app.post("/token", tags=["authentication"], summary="Obtain an OAuth2 token")
async def login_for_access_token(
username: str = Field(..., description="User's email for login"),
password: str = Field(..., description="User's password")
):
# In a real app, validate username/password against stored credentials
if username == "admin@example.com" and password == "secret":
# In a real app, generate a JWT token
return {"access_token": "secure-token-123", "token_type": "bearer"}
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="Incorrect username or password",
headers={"WWW-Authenticate": "Bearer"},
)
ด้วยการกำหนด `OAuth2PasswordBearer` และใช้ร่วมกับ `Depends` FastAPI จะเพิ่มปุ่ม "Authorize" ใน Swagger UI ของคุณโดยอัตโนมัติ ทำให้นักพัฒนาสามารถป้อนโทเค็นและทดสอบจุดสิ้นสุดที่ต้องมีการยืนยันตัวตนได้โดยตรง สิ่งนี้ช่วยปรับปรุงประสบการณ์นักพัฒนาสำหรับ API ที่ปลอดภัยได้อย่างมาก
การปรับแต่งขั้นสูงและแนวทางปฏิบัติที่ดีที่สุด
แม้ว่าค่าเริ่มต้นของ FastAPI จะยอดเยี่ยม แต่คุณอาจพบสถานการณ์ที่ต้องควบคุมการสร้างเอกสารหรือการนำเสนอมากขึ้น
การปรับแต่ง Swagger UI และ ReDoc
FastAPI ช่วยให้สามารถปรับแต่ง UI เอกสารประกอบในตัวได้โดยการส่งพารามิเตอร์ไปยังคอนสตรักเตอร์ `FastAPI`:
- `swagger_ui_parameters`: พจนานุกรมของพารามิเตอร์ที่จะส่งไปยัง Swagger UI (เช่น เพื่อเปลี่ยนการจัดเรียงเริ่มต้นของการดำเนินการ หรือเปิดใช้งาน deep linking)
- `redoc_ui_parameters`: พจนานุกรมของพารามิเตอร์สำหรับ ReDoc
- `docs_url` และ `redoc_url`: เปลี่ยนพาธที่ UI เอกสารจะถูกให้บริการ หรือตั้งค่าเป็น `None` เพื่อปิดใช้งานหากคุณให้บริการเอกสารที่กำหนดเอง
ตัวอย่างสำหรับการปรับแต่ง Swagger UI:
app = FastAPI(
title="Customized Docs API",
swagger_ui_parameters={"docExpansion": "list", "filter": True}
)
สิ่งนี้จะทำให้ Swagger UI ขยายเฉพาะรายการของการดำเนินการและเพิ่มแถบตัวกรอง
การสร้างโค้ดไคลเอ็นต์และ SDKs
หนึ่งในข้อได้เปรียบที่ทรงพลังที่สุดของ OpenAPI specification ที่เครื่องจักรสามารถอ่านได้ คือความสามารถในการสร้างไลบรารีไคลเอ็นต์ (SDKs) โดยอัตโนมัติในภาษาโปรแกรมต่างๆ เครื่องมือเช่น OpenAPI Generator สามารถนำไฟล์ `openapi.json` ของคุณไปสร้างโค้ดไคลเอ็นต์ที่พร้อมใช้งานได้ สิ่งนี้มีคุณค่าอย่างยิ่งสำหรับทีมงานทั่วโลก เนื่องจากช่วยให้นักพัฒนาสามารถรวมเข้ากับ API ของคุณได้อย่างรวดเร็วโดยใช้ภาษาที่ต้องการ โดยไม่ต้องเขียนโค้ด boilerplate ด้วยตนเอง ตัวอย่างเช่น นักพัฒนา Java ในเบอร์ลิน นักพัฒนา Node.js ในโตเกียว และนักพัฒนา C# ในนิวยอร์ก ล้วนสามารถใช้ SDKs ที่สร้างขึ้นโดยอัตโนมัติสำหรับ API Python FastAPI ของคุณได้
การกำหนดเวอร์ชันเอกสาร API ของคุณ
เมื่อ API ของคุณพัฒนาขึ้น คุณอาจจะมีการแนะนำเวอร์ชันใหม่ การจัดทำเอกสารเวอร์ชันเหล่านี้อย่างชัดเจนเป็นสิ่งจำเป็น แม้ว่า FastAPI จะสร้าง OpenAPI spec เดียวโดยอัตโนมัติ คุณสามารถจัดการเวอร์ชันได้โดย:
- การกำหนดเวอร์ชัน URL: รวมเวอร์ชันไว้ในพาธ URL (เช่น `/v1/items`, `/v2/items`) จากนั้นคุณจะมีแอปพลิเคชัน `FastAPI` (หรือ APIRouters) แยกต่างหากสำหรับแต่ละเวอร์ชัน ซึ่งแต่ละรายการจะสร้าง OpenAPI schema ของตนเอง
- การกำหนดเวอร์ชัน Header: ใช้ header ที่กำหนดเอง (เช่น `X-API-Version: 1`) วิธีนี้แยกแยะได้ยากกว่าสำหรับการจัดทำเอกสารอัตโนมัติ แต่สามารถจัดการได้ด้วยการสร้าง OpenAPI แบบกำหนดเอง หรือโดยการให้บริการเอกสารสำหรับค่า header เฉพาะ
สำหรับสถานการณ์การกำหนดเวอร์ชันที่ซับซ้อน คุณอาจต้องรวมอินสแตนซ์ `APIRouter` หลายรายการเข้าด้วยกันภายในแอปพลิเคชัน FastAPI เดียว ซึ่งแต่ละรายการมี `prefix` ของตนเอง (เช่น `/v1` หรือ `/v2`) และอาจมีการแทนที่ `openapi_url` สำหรับการสร้าง schema แยกต่างหาก
ขั้นตอนการทำงานของการจัดทำเอกสารแบบร่วมมือ
การรวมการสร้างเอกสารเข้ากับ Continuous Integration/Continuous Deployment (CI/CD) pipeline ของคุณ ทำให้มั่นใจว่า OpenAPI spec ของคุณเป็นปัจจุบันและพร้อมใช้งานอยู่เสมอ คุณสามารถตั้งค่างานที่ดึงข้อมูลจุดสิ้นสุด `openapi.json` ของแอปพลิเคชันที่ปรับใช้ของคุณ หรือแม้กระทั่งในระหว่างการสร้าง แล้วเผยแพร่ไฟล์ JSON นี้ไปยังพอร์ทัลเอกสารกลางหรือระบบควบคุมเวอร์ชัน สิ่งนี้ช่วยให้ทีมอื่นหรือพันธมิตรภายนอกสามารถเข้าถึงสัญญา API ล่าสุดได้เสมอ ส่งเสริมการทำงานร่วมกันทั่วโลกอย่างราบรื่น
การทำเอกสารเป็นสากล (ข้อควรพิจารณา)
แม้ว่า UI เอกสารที่สร้างโดย FastAPI จะเป็นภาษาอังกฤษโดยธรรมชาติ แต่เนื้อหาที่คุณให้มา (คำอธิบาย, สรุป, ตัวอย่าง) ควรถูกสร้างขึ้นโดยคำนึงถึงผู้ชมทั่วโลก:
- ภาษาที่ชัดเจนและกระชับ: หลีกเลี่ยงคำแสลง สำนวน หรือสำนวนเฉพาะวัฒนธรรม ใช้ภาษาอังกฤษที่เรียบง่ายและตรงไปตรงมาซึ่งเข้าใจง่ายสำหรับผู้ที่ไม่ได้ใช้ภาษาอังกฤษเป็นภาษาแม่
- ตัวอย่างที่เป็นสากล: เมื่อให้ตัวอย่างสำหรับ request bodies หรือ query parameters ให้ใช้ข้อมูลที่เกี่ยวข้องทั่วโลก (เช่น รูปแบบวันที่มาตรฐาน, ชื่อผู้ใช้ทั่วไป, ID ผลิตภัณฑ์ระหว่างประเทศ) หากจำเป็นต้องมีตัวอย่างเฉพาะภูมิภาค ให้ระบุอย่างชัดเจน
- การเข้าถึง: ตรวจสอบให้แน่ใจว่าคำอธิบายของคุณละเอียดถี่ถ้วนพอที่จะสื่อความหมายได้โดยไม่ต้องอาศัยความรู้ทางวัฒนธรรมโดยนัย
สำหรับเอกสารที่เป็นหลายภาษาอย่างแท้จริง คุณจะต้องส่งออก OpenAPI spec และใช้เครื่องมือภายนอกที่ออกแบบมาสำหรับการทำเอกสารเป็นสากล แต่เอกสาร OpenAPI พื้นฐานยังคงเป็นกลางต่อภาษาในโครงสร้างของมัน
ผลกระทบในโลกแห่งความเป็นจริงและการนำไปใช้ทั่วโลก
การทำงานร่วมกันระหว่าง Python FastAPI และ OpenAPI มีผลกระทบอย่างลึกซึ้งต่อการพัฒนา API ในโลกแห่งความเป็นจริง โดยเฉพาะอย่างยิ่งสำหรับองค์กรที่ดำเนินงานในระดับโลก:
- เวลาออกสู่ตลาดเร็วขึ้น: ด้วยการทำให้เอกสารเป็นไปโดยอัตโนมัติ ทีมพัฒนาสามารถมุ่งเน้นไปที่ตรรกะทางธุรกิจหลักได้มากขึ้น ทำให้การเปิดตัวคุณสมบัติและบริการใหม่ๆ ทั่วโลกเร็วขึ้น
- ลดภาระในการรวมระบบ: นักพัฒนาที่ใช้ API ไม่ว่าจะอยู่ที่ใดหรือใช้ภาษาโปรแกรมใดก็ตาม จะได้รับประโยชน์จากเอกสารที่โต้ตอบได้ แม่นยำ และ SDK ไคลเอ็นต์ที่พร้อมใช้งาน ซึ่งช่วยลดเวลาและความพยายามในการรวมระบบได้อย่างมาก
- กลยุทธ์ผลิตภัณฑ์ API ที่ดีขึ้น: API ที่มีเอกสารดีจะง่ายต่อการทำการตลาด การรวมเข้ากับพันธมิตร และการเสนอเป็นบริการ สิ่งนี้อำนวยความสะดวกในการขยายธุรกิจทั่วโลกและการทำงานร่วมกับพันธมิตรที่หลากหลาย
- ประสบการณ์นักพัฒนา (DX) ที่ดีขึ้น: ประสบการณ์นักพัฒนาที่เหนือกว่าคือความได้เปรียบในการแข่งขัน เอกสารอัตโนมัติของ FastAPI มีส่วนสำคัญในเรื่องนี้โดยทำให้ API เป็นที่น่าใช้ ดึงดูดนักพัฒนามากขึ้น และส่งเสริมการสร้างนวัตกรรมทั่วโลก องค์กรจำนวนมาก ตั้งแต่สตาร์ทอัพไปจนถึงองค์กรขนาดใหญ่ในทวีปต่างๆ กำลังนำ FastAPI มาใช้เพื่อประโยชน์เหล่านี้โดยเฉพาะ โดยตระหนักถึงคุณค่าของแนวทางในการจัดทำเอกสาร API
สรุป: ยกระดับการพัฒนา API ของคุณด้วย FastAPI และ OpenAPI
สรุปได้ว่า การสนับสนุน OpenAPI Specification โดยกำเนิดของ Python FastAPI เป็นตัวเปลี่ยนเกมสำหรับการพัฒนา API มันเปลี่ยนงานการทำเอกสารที่มักจะน่าเบื่อหน่ายและมีแนวโน้มที่จะเกิดข้อผิดพลาดให้เป็นกระบวนการอัตโนมัติ ราบรื่น และมีประสิทธิภาพสูง ด้วยการใช้ประโยชน์จาก Python type hints และ Pydantic FastAPI จะสร้าง OpenAPI schema ที่ถูกต้องและเครื่องจักรสามารถอ่านได้ ซึ่งขับเคลื่อน UI เอกสารแบบโต้ตอบ เช่น Swagger UI และ ReDoc
สำหรับทีมพัฒนาทั่วโลก ผู้ใช้ API ในภูมิภาคต่างๆ และองค์กรที่มุ่งเน้นการรวมระบบที่ราบรื่นและผลิตภัณฑ์ API ที่แข็งแกร่ง FastAPI นำเสนอโซลูชันที่ไม่มีใครเทียบได้ มันรับประกันว่าเอกสาร API ของคุณจะซิงโครไนซ์กับโค้ดเบสของคุณอยู่เสมอ มีรายละเอียดที่สมบูรณ์ และเข้าถึงได้อย่างน่าทึ่ง น้อมรับ FastAPI เพื่อยกระดับการพัฒนา API ของคุณ ส่งเสริมการทำงานร่วมกันที่ดีขึ้น และมอบประสบการณ์นักพัฒนาที่ยอดเยี่ยมทั่วโลก
เริ่มสร้าง API ถัดไปของคุณด้วย FastAPI วันนี้ และสัมผัสพลังของเอกสารอัตโนมัติระดับโลก!