แปลง JSON เป็น Python: สร้าง Dataclass และ Pydantic Model ได้ทันที

ใครเขียน Python service ที่ต้องเรียก HTTP API คงคุ้นเคยกับ scene นี้ดี: sample JSON response มาถึง แล้วครึ่งชั่วโมงต่อมาหายไปกับการนั่งเขียน class ให้ตรงกับมัน — เลือก type ให้แต่ละ field, ไล่ดูว่า field ไหนเป็น None ได้, แปลง key จาก camelCase เป็น snake_case แค่ลืมจัดการ nullable สักจุดเดียว TypeError ก็รอวันระเบิดใน production เสมอ

JSON to Python Converter เปลี่ยนงานนี้ให้เหลือแค่ paste แล้ว copy วาง JSON sample ลงไปแล้วจะได้ Python class ที่สะอาดสองแบบให้เลือก — dataclass ล้วนๆ หรือ Pydantic model — โดย JSON ที่ซ้อนกันกลายเป็น nested classes, ค่าที่หายไปหรือเป็น null กลายเป็น Optional[...] fields พร้อม None defaults และ key แบบ camelCase ถูกแปลงเป็น snake_case ตามมาตรฐาน PEP 8 พร้อม alias ที่ทำให้ wire format เดิมยัง parse ได้ ทุกอย่างทำงานใน browser ของคุณล้วนๆ payload ของคุณจึงไม่มีทางออกนอกเครื่อง

ในบทความนี้เราจะพาดูว่า converter ทำงานยังไง, เลือก dataclass หรือ Pydantic ยังไงดี และ use case แบบไหนที่มันช่วยประหยัดเวลาได้มากที่สุด

ทำไมต้องใช้ JSON to Python Converter?

• สองสไตล์ output จาก input เดียว. สลับระหว่าง dataclass ของ standard library กับ Pydantic BaseModel — จะเอาแบบไม่พึ่ง dependency หรือแบบมี runtime validation ก็เลือกได้เลย
• JSON ที่ซ้อนกันกลายเป็น nested classes. object customer ที่ซ้อนอยู่กลายเป็น class Customer ของตัวเอง โดยถูก emit ไว้ก่อน class ที่เรียกใช้มัน
• Optional[...] ตรงจุดที่ควรเป็น. เปิด switch สำหรับ optional fields แล้วทุก field จะกลายเป็น Optional[T] = None ตรงกับ payload จริงที่ key มักหายไปหรือเป็น null
• แปลงเป็น snake_case พร้อม aliases. orderTotal กลายเป็น order_total ตาม PEP 8 และฝั่ง Pydantic เก็บ Field(alias="orderTotal") ไว้ให้ deserialize ทำงานได้ต่อ
• 100% client-side และฟรี. การแปลงเกิดขึ้นใน browser ทั้งหมด — ไม่ต้องสมัคร ไม่มี upload ไม่มี server round-trip

ฟีเจอร์เด่น

มีสองจุดที่น่าพูดถึงเพิ่ม บล็อก import นั้นครบจริงๆ: typing imports จะปรากฏเมื่อโค้ดใช้จริงเท่านั้น และฝั่ง Pydantic ใส่ comment # pip install pydantic มาให้ snippet รันได้หลัง install รอบเดียว ส่วน root ที่ไม่ใช่ object ก็จัดการได้ — วาง array หรือ primitive แล้วเครื่องมือจะแถม comment Root = ... พร้อม type ที่ infer ได้ให้ด้วย

วิธีใช้งาน

1. วาง JSON ของคุณลงใน input panel — เป็น object, array หรือแม้แต่ primitive เดี่ยวๆ ก็ได้
2. เลือก output style: dataclass สำหรับโปรเจกที่ใช้ standard library ล้วน, Pydantic เมื่ออยากได้ validation
3. สลับ options: snake_case field names และ Optional[...] fields พร้อม None defaults
4. Copy classes ที่ได้ — imports, decorators และลำดับ class มาครบตั้งแต่ใน output panel
5. เอาไปวางในโปรเจก แล้วรัน pip install pydantic ถ้าเลือกสไตล์นั้น

Dataclass vs Pydantic

สองสไตล์นี้ให้ class รูปร่างเดียวกัน แต่ behavior ตอน runtime ต่างกันมาก — การเลือกให้ถูกชั้นจึงสำคัญกว่าที่คิด

เมื่อ dataclass ธรรมดาเพียงพอ. Dataclasses อยู่ใน standard library ตั้งแต่ Python 3.7 ไม่มีต้นทุน import และ instantiate เร็วกว่า validated models สำหรับข้อมูลที่เชื่อถือได้ — ไฟล์ internal, dict ที่โค้ดเราสร้างเอง, test fixture — มันให้ attribute แบบ typed อ่านรู้เรื่องโดยไม่ต้องพึ่ง dependency เพิ่ม

เมื่อ Pydantic คุ้มค่ากับที่ลง. ที่ system boundary — parse API response, โหลด config, รับ webhook — ข้อมูลคือสิ่งที่เชื่อถือไม่ได้ ตรงนั้นแหละที่ Pydantic คุ้ม: มัน coerce type ตอนรับเข้า, raise ValidationError พร้อมระบุ field path ที่ผิดเป๊ะๆ และเข้ากับ FastAPI ได้ในตัว การใช้ generated models ที่ขอบระบบทำให้ payload ที่เสียระเบิดดังๆ ตั้งแต่เนิ่นๆ แทนที่จะปนเปื้อนเข้าไปใน domain objects

ความหมายของ Optional[...] และ None defaults. Optional[str] แปลว่าค่าเป็น string หรือ None — ตัวมันเองไม่ได้ทำให้ field ข้ามได้ ในทั้งสองสไตล์ field ที่ไม่มี default ยังคงเป็น required ซึ่งเป็นเหตุผลที่เครื่องมือคู่ annotation กับ = None เสมอ ส่วน null ใน sample จะ infer เป็น Any — สัญญาณให้รีบเปลี่ยนเป็น type จริงเมื่อรู้รูปร่างที่แน่นอน

แปลงเป็น snake_case ด้วย aliases. ใน output ฝั่ง Pydantic Field(alias="orderTotal") ทำให้โค้ดอ่าน order_total ขณะที่ model parse key แบบ camelCase จาก wire Dataclasses ไม่มี alias support ในตัว — อีกเหตุผลที่ Pydantic เหมาะกับ payload จากภายนอกที่สุด

List[...] และ nested models. array กลายเป็น List[T] ตาม element ตัวแรก และ object ที่ซ้อนอยู่กลายเป็น class เต็มรูปแบบ ลองดู sample payload นี้:

{
  "order_id": 1042,
  "orderTotal": 91.5,
  "couponCode": null,
  "customer": {
    "userName": "ada",
    "email": "[email protected]"
  },
  "tags": ["priority", "gift"]
}

output ฝั่ง dataclass (เปิด optional fields):

from dataclasses import dataclass
from typing import Any, List, Optional

@dataclass
class Customer:
    user_name: Optional[str] = None
    email: Optional[str] = None

@dataclass
class Order:
    order_id: Optional[int] = None
    order_total: Optional[float] = None
    coupon_code: Optional[Any] = None
    customer: Optional[Customer] = None
    tags: Optional[List[str]] = None

output ฝั่ง Pydantic (เปิด optional fields):

from pydantic import BaseModel, Field
from typing import Any, List, Optional

# pip install pydantic

class Customer(BaseModel):
    user_name: Optional[str] = Field(default=None, alias="userName")
    email: Optional[str] = None

class Order(BaseModel):
    order_id: Optional[int] = None
    order_total: Optional[float] = Field(default=None, alias="orderTotal")
    coupon_code: Optional[Any] = Field(default=None, alias="couponCode")
    customer: Optional[Customer] = None
    tags: Optional[List[str]] = None

รูปร่างเหมือนกัน — แต่มีเฉพาะฝั่ง Pydantic ที่มี alias และมีเฉพาะมันที่ปฏิเสธ string ใน field order_total ที่ควรเป็นตัวเลข

กรณีใช้งานจริง

API Clients

กำลังเขียน wrapper ให้ REST API ของ third party ที่ documentation โชว์ response 40 fields? วาง sample ลงใน JSON to Python Converter เลือก Pydantic แล้วคุณจะมี model พร้อม alias ในไม่กี่วินาที พอ API อัปเดต field ใหม่ก็วางใหม่แล้ว regenerate — เร็วกว่าแก้มือแน่นอน

ETL Scripts

งาน extract-and-load อยู่รอดด้วย schema ที่ชัดเจน สร้าง dataclass ให้ record ที่ไหลระหว่างระบบแล้วทุก stage ของ pipeline จะได้ autocomplete ใน IDE และ annotation ที่ mypy ตรวจได้ ผิดรูปเมื่อไร fail ทันที ไม่ใช่ส่ง dict เงียบๆ ต่อกันไป

Test Fixtures

เก็บ response จริงหนึ่งชุดต่อหนึ่ง endpoint สร้าง model รอบเดียวแล้วเขียน fixture บน model นั้น เทสต์จะพังทันทีเมื่อ schema เปลี่ยน — ไม่ใช่ลึกถึง assertion ที่สามค่อยรู้ตัว

Config Loading

วาง config sample ที่ลบความลับออกแล้ว สร้าง Pydantic models แล้วตอน startup validation จะปฏิเสธบูตถ้า setting หายหรือ type ผิด — พร้อม error ที่ชี้ชื่อ field มาเลย

แนวปฏิบัติที่ดี

• Validate กับ payload จริง. สร้างจาก API response จริงเพื่อให้ nullable field และ key แปลกๆ ถูกจับได้ แล้วค่อยปรับให้แน่นขึ้น
• เก็บ alias ไว้สำหรับ wire format. ให้ Field(alias=...) เป็นเจ้าของการแปลง แทนการเปลี่ยนชื่อ key ของ API ด้วยมือ
• Regenerate เมื่อ API เปลี่ยน. การ regenerate ฟรีๆ หลัง version bump ชนะการไล่ diff payload ด้วยตา
• เปลี่ยน Any เป็น type จริง. พอรู้ว่า field ที่เคยเป็น null ถือค่าอะไร แก้ Optional[Any] เป็น Optional[str] หรือ nested model
• Pydantic ที่ขอบระบบ, dataclass ข้างใน. Validate input ที่เชื่อถือไม่ได้ที่ขอบ แล้วส่ง dataclass ธรรมดาต่อใน core logic
• เก็บ generated models ไว้ module แยก. การถือว่ามันเป็น artifact ที่ regenerate ได้ ทำให้ type ซื่อสัตย์และ diff อ่านง่าย

เริ่มแปลง JSON เป็น Python Model วันนี้

หยุดนั่งแปลง API response ทีละ field ได้แล้ว JSON to Python Converter เปลี่ยน JSON sample ใดๆ เป็น dataclass หรือ Pydantic model ภายในไม่ถึงวินาที — nested classes, Optional[...] fields, aliases และ imports จัดการครบ ทำงานใน browser ล้วนๆ วาง payload แรกของคุณแล้ว copy ผลลัพธ์เข้า codebase ได้เลย

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• JSON Formatter — จัดรูปและตรวจ payload ก่อนเอาไปสร้าง model
• JSON to Go Struct Converter — workflow เดียวกันสำหรับคนเขียน Go
• OpenAPI to TypeScript Converter — สร้าง TypeScript clients แบบ typed จาก API specs โดยตรง

ขอให้สนุกกับการ modeling!

คำถามที่พบบ่อย

ถ: JSON ของฉันถูกอัปโหลดขึ้น server ไหม?

ตอบ: ไม่ การ parse และสร้างโค้ดเกิดขึ้นใน browser ด้วย JavaScript ทั้งหมด — ไม่มีการส่ง เก็บ หรือ log ข้อมูล และเครื่องมือใช้แบบ offline ได้เมื่อหน้าโหลดแล้ว

ถ: ควรเลือก output แบบ dataclass หรือ Pydantic เมื่อไร?

ตอบ: Dataclass สำหรับข้อมูล internal ที่เชื่อถือได้ซึ่งไม่อยากพึ่ง dependency — ETL records, domain objects, fixtures ส่วน Pydantic เหมาะที่ boundary อย่าง API clients และ config loading ที่ validation, type coercion และ ValidationError คุ้มค่าจริง

ถ: null และ field ที่หายไปถูกจัดการอย่างไร?

ตอบ: null จะ infer เป็น Any และเมื่อเปิด switch optional fields ทุก field จะเป็น Optional[T] พร้อม None default เพื่อให้ key ข้ามได้ จำไว้ว่า Optional[T] อย่างเดียวไม่ได้ทำให้ field เป็น optional — None default ต่างหากที่ทำ

ถ: key แบบ camelCase ใน JSON กลายเป็นอะไร?

ตอบ: ถูกแปลงเป็น snake_case ตาม PEP 8 และฝั่ง Pydantic เก็บ key เดิมไว้เป็น field alias ทำให้ model ยัง deserialize payload จริงได้ขณะที่โค้ดใช้ชื่อแบบ Pythonic