camelCase หรือ snake_case: ชื่อฟิลด์ JSON แบบไหนดีกว่า

ในสถาปัตยกรรมของระบบแบบกระจาย (distributed systems) API ไม่ได้เป็นเพียงช่องทางสำหรับการสื่อสารระหว่างระบบเท่านั้น แต่ยังเป็นสัญญาที่เชื่อมโยงเทคโนโลยีสแต็กที่แตกต่างกัน วัฒนธรรมองค์กร และแม้กระทั่งยุคของการพัฒนา ภายในรายละเอียดการออกแบบของ RESTful API มีหัวข้อที่ดูเหมือนเล็กน้อยแต่กลับก่อให้เกิดการถกเถียงไม่รู้จบ: ชื่อฟิลด์ JSON ควรสลับใช้ camelCase หรือ snake_case ดี?

นี่ไม่ใช่แค่ทางเลือกด้านสุนทรียศาสตร์เท่านั้น แต่ยังเกี่ยวข้องกับ "ความไม่เข้ากัน" (impedance mismatch) ระหว่างเลเยอร์การจัดเก็บข้อมูลแบ็กเอนด์ (backend persistence layers) และเลเยอร์การนำเสนอข้อมูลส่วนหน้า (frontend presentation layers) ซึ่งครอบคลุมถึงประสิทธิภาพการซีเรียลไลซ์ (serialization performance) ประสิทธิภาพการส่งผ่านเครือข่าย ประสบการณ์ของนักพัฒนา (DX) และจิตวิทยาการรับรู้

บทความนี้จะนำเสนอแนวทางในการตัดสินใจในระดับผู้เชี่ยวชาญ โดยอิงจากประวัติศาสตร์ของภาษาโปรแกรม กลไกการนำไปใช้ทางเทคนิคที่ซ่อนอยู่ และการตัดสินใจด้านสถาปัตยกรรมของบริษัทยักษ์ใหญ่ในอุตสาหกรรม เช่น Google และ Stripe

1. ต้นกำเนิดทางประวัติศาสตร์: ทางเลือกเชิงสัญวิทยา

เพื่อให้เข้าใจการถกเถียงนี้ เราต้องย้อนรอยวิวัฒนาการของภาษาคอมพิวเตอร์ หลักการตั้งชื่อไม่ได้เกิดขึ้นมาลอยๆ แต่เป็นผลผลิตของข้อจำกัดด้านฮาร์ดแวร์และวัฒนธรรมของชุมชนในแต่ละยุคสมัย

ต้นกำเนิดของ snake_case: C และปรัชญา Unix

ความนิยมของ snake_case (เช่น user_id) ย้อนกลับไปในยุคปี 1970 กับภาษา C และระบบ Unix แม้ว่าแป้นพิมพ์ยุคแรก (เช่น Teletype Model 33) จะมีปุ่ม Shift แต่คอมไพเลอร์ยุคแรกจำนวนมากไม่คำนึงถึงตัวพิมพ์เล็กใหญ่ (case-insensitive) เพื่อให้แยกคำได้อย่างชัดเจนบนหน้าจอที่มีความละเอียดต่ำ นักพัฒนาโปรแกรมจึงใช้เครื่องหมายขีดล่าง (underscore) เพื่อจำลองช่องว่างในภาษาธรรมชาติ พฤติกรรมนี้ฝังรากลึกในมาตรฐานฐานข้อมูล SQL จนถึงทุกวันนี้ รูปแบบการตั้งชื่อคอลัมน์เริ่มต้นสำหรับ PostgreSQL และ MySQL ยังคงเป็น snake_case ซึ่งเป็นการวางรากฐานสำหรับปัญหาการจับคู่ (mapping friction) ระหว่าง API และฐานข้อมูลในอนาคต

การผงาดขึ้นของ camelCase: การครอบงำของ Java และ JavaScript

camelCase (เช่น userId) ได้รับความนิยมพร้อมกับการเขียนโปรแกรมเชิงวัตถุ (Smalltalk, C++, Java) Java ได้กำหนดมาตรฐานอุตสาหกรรมคือ "PascalCase สำหรับคลาส และ camelCase สำหรับเมธอด/ตัวแปร" จุดเปลี่ยนที่สำคัญคือการกำเนิดของ JavaScript แม้ว่า JSON จะมีต้นกำเนิดมาจาก JS object literals แต่ไลบรารีมาตรฐานของ JS (เช่น getElementById) ก็ใช้ camelCase อย่างแพร่หลาย และเมื่อ AJAX กับ JSON เข้ามาแทนที่ XML ในฐานะรูปแบบการแลกเปลี่ยนข้อมูลที่แพร่หลาย camelCase ก็ได้รับสถานะ "ดั้งเดิม" ในโลกของเว็บ

2. ความขัดแย้งหลัก: ความไม่เข้ากันของเทคโนโลยีสแต็ก

เมื่อข้อมูลไหลเวียนระหว่างภาษาโปรแกรมที่แตกต่างกัน ย่อมหลีกเลี่ยงไม่ได้ที่จะเผชิญกับ "ความไม่เข้ากัน" (impedance mismatch)

มุมมองจากฝั่งแบ็กเอนด์ (Python/Ruby/SQL)

ในฝั่งแบ็กเอนด์ ชุมชน Python (PEP 8) และ Ruby แนะนำอย่างยิ่งให้ใช้ snake_case

• Python/Django/FastAPI: โมเดล Pydantic ของคุณมักจะสอดคล้องโดยตรงกับโครงสร้างตารางฐานข้อมูล:

class UserProfile(BaseModel):
    first_name: str  # Python convention
    last_name: str

หาก API กำหนดให้ใช้ camelCase คุณจะต้องกำหนดค่านามแฝง (aliases) หรือตัวแปลง (converters) ในเลเยอร์การซีเรียลไลซ์ แม้จะทำได้ แต่สิ่งนี้จะเพิ่มเลเยอร์ของตรรกะการแมป

• ฐานข้อมูล SQL: ชื่อคอลัมน์ฐานข้อมูลส่วนใหญ่ใช้ snake_case หาก API ใช้ camelCase เลเยอร์ ORM จะต้องจัดการการแปลงข้อมูลอย่างสม่ำเสมอ
• ทางเลือกของ Stripe: เหตุผลที่ Stripe และ GitHub เลือกใช้ snake_case อย่างแน่วแน่ ส่วนใหญ่เป็นเพราะสถาปัตยกรรมแรกเริ่มของพวกเขาถูกสร้างขึ้นบน Ruby stack การเปิดเผยโมเดลภายในโดยตรงทำให้มั่นใจได้ถึงความสอดคล้องของแบ็กเอนด์

มุมมองจากฝั่งฟรอนต์เอนด์ (JavaScript/TypeScript)

ในเบราว์เซอร์ camelCase คือผู้ปกครองโดยสมบูรณ์

• ความแตกแยกของรูปแบบโค้ด: หาก API ส่งคืน snake_case โค้ดฝั่งฟรอนต์เอนด์จะมีความไม่สอดคล้องกัน:

const user = await fetchUser();
console.log(user.first_name); // Violates ESLint camelcase rule
render(user.email_address);

ESLint จะแจ้งเตือนสิ่งนี้เป็นคำเตือน บังคับให้นักพัฒนาต้องปิดใช้งานกฎดังกล่าว หรือแปลงข้อมูลทันทีที่ได้รับ

• ความยุ่งยากในการ Destructuring: ในการพัฒนา JS/TS สมัยใหม่ การแยกโครงสร้างอ็อบเจกต์ (object destructuring) เป็นสิ่งที่พบได้ทั่วไป หากฟิลด์เป็น snake_case จะต้องเปลี่ยนชื่อในระหว่างการแยกโครงสร้าง เพื่อหลีกเลี่ยงการทำให้ขอบเขตท้องถิ่น (local scope) ปนเปื้อน:

// Verbose renaming
const { first_name: firstName, last_name: lastName } = response.data;

สิ่งนี้เพิ่มโค้ดที่ซ้ำซ้อน (boilerplate code) และโอกาสที่จะเกิดข้อผิดพลาด

3. ความเชื่อผิดๆ ด้านประสิทธิภาพ: การซีเรียลไลซ์และการส่งผ่านเครือข่าย

เกี่ยวกับประสิทธิภาพ มีความเชื่อผิดๆ สองอย่างที่พบบ่อย: "การแปลงชื่อฟิลด์ช้าเกินไป" และ "เครื่องหมายขีดล่างเพิ่มขนาดเพย์โหลด" มาทำความเข้าใจให้ชัดเจนด้วยข้อมูลกัน

ความเชื่อที่ 1: ค่าใช้จ่ายส่วนเกินจากการแปลงข้อมูลขณะรันไทม์

• ภาษาแบบไดนามิก (Dynamic Languages): ใน Python หรือ Ruby การแปลงชื่อฟิลด์ผ่านการแทนที่ด้วย Regex ในทุกคำขอจะใช้ CPU อย่างแน่นอน อย่างไรก็ตาม เฟรมเวิร์กสมัยใหม่ (เช่น Pydantic v2 ที่เขียนใหม่ใน Rust) ลดค่าใช้จ่ายส่วนเกินนี้โดยใช้การแมป Schema ที่คำนวณไว้ล่วงหน้า
• ภาษาแบบคงที่ (Static Languages) (Go/Java/Rust): สิ่งนี้แทบจะเรียกได้ว่า "ไม่มีต้นทุน" (zero cost) เลยแท็กโครงสร้างของ Go (json:"firstName") หรือแคชการแมปของ Java Jackson จะถูกกำหนดในขณะคอมไพล์หรือตอนเริ่มต้น การทำงานขณะรันไทม์เกี่ยวข้องกับการคัดลอกไบต์ง่ายๆ ไม่ใช่การคำนวณแบบไดนามิก

ข้อควรจำ: อย่าทำการแปลงข้อมูลแบบวนซ้ำทั่วทั้งระบบในฝั่งฟรอนต์เอนด์ (เทรดหลักของเบราว์เซอร์) โดยใช้ interceptors (เช่น Axios) สำหรับการตอบสนองขนาดใหญ่ สิ่งนี้จะทำให้หน้าเว็บกระตุกและใช้หน่วยความจำมาก สรุป: แบ็กเอนด์ควรจัดการการแปลงนี้

ความเชื่อที่ 2: ขนาดการส่งและบีบอัดข้อมูล

ตามทฤษฎีแล้ว first_name จะยาวกว่า firstName หนึ่งไบต์ อย่างไรก็ตาม เมื่อเปิดใช้งานการบีบอัดด้วย Gzip หรือ Brotli (ซึ่งเป็นการตั้งค่า HTTP มาตรฐาน) ความแตกต่างนี้ก็แทบจะหายไป

• หลักการ: อัลกอริทึมการบีบอัดอาศัย "การอ้างอิงสตริงที่ซ้ำกัน" (duplicate string referencing) ในอาร์เรย์ JSON คีย์จะมีการซ้ำกันสูง อัลกอริทึมจะจัดเก็บ first_name ไว้ในพจนานุกรมเมื่อพบครั้งแรก และแทนที่การปรากฏครั้งต่อไปด้วยพอยน์เตอร์ขนาดเล็ก
• การทดสอบประสิทธิภาพ: การทดสอบแสดงให้เห็นว่าภายใต้ Gzip ระดับ 6 ความแตกต่างของขนาดระหว่างทั้งสองรูปแบบมักจะอยู่ระหว่าง 0.5% ถึง 1% เว้นแต่คุณกำลังส่งข้อมูลผ่านลิงก์ดาวเทียม นี่ไม่ใช่ปัญหาที่สำคัญ

4. ประสบการณ์ของนักพัฒนา (DX) และจิตวิทยาการรับรู้

สถาปัตยกรรมไม่ได้เป็นเพียงเรื่องของเครื่องจักรเท่านั้น แต่ยังเกี่ยวกับผู้คนด้วย

• ความอ่านง่ายของ snake_case: จิตวิทยาการรับรู้ชี้ให้เห็นว่าเครื่องหมายขีดล่างช่วยให้เกิดการแยกด้วยสายตาที่ชัดเจน สมองประมวลผล parse_db_xml ได้เร็วกว่า parseDbXml โดยเฉพาะอย่างยิ่งเมื่อต้องจัดการกับคำย่อที่ต่อเนื่องกัน (เช่น XMLHTTPRequest เทียบกับ XmlHttpRequest) นี่คือเหตุผลหนึ่งที่เอกสารของ Stripe ได้รับการพิจารณาว่าอ่านง่ายมาก
• ความสอดคล้องของ camelCase: สภาวะการไหลลื่น (flow state) ที่เกิดจากความสอดคล้องกันแบบ Full-stack นั้นมีความสำคัญมากกว่า สำหรับทีม JS/TS แบบ Full-stack การใช้ camelCase ทั้งในส่วนหน้าและส่วนหลัง ช่วยให้สามารถนำคำจำกัดความประเภท (Interface/Zod Schema) มาใช้ซ้ำได้โดยตรง ซึ่งช่วยขจัดภาระทางความคิดของการ "แปลความหมายในใจ" ได้อย่างสมบูรณ์

5. มาตรฐานอุตสาหกรรมและเหตุผล

6. คำแนะนำเชิงสถาปัตยกรรมขั้นสูง: การแยกส่วน (Decoupling) และ DTOs

รูปแบบที่ไม่ควรปฏิบัติที่พบบ่อยคือ "การส่งผ่านตรง" (Pass-through): คือการซีเรียลไลซ์เอนทิตีฐานข้อมูลโดยตรงเพื่อส่งคืน

• หากคุณทำเช่นนี้ และคอลัมน์ DB ของคุณเป็น snake_case API ของคุณก็จะกลายเป็น snake_case ไปด้วย
• ความเสี่ยง: การทำเช่นนี้ละเมิดหลักการซ่อนข้อมูล (information hiding) เปิดเผยโครงสร้างตาราง และสร้างความผูกพันที่แน่นแฟ้น (strong coupling) ระหว่าง API และ DB หากมีการเปลี่ยนชื่อ DB API ก็จะใช้งานไม่ได้

แนวทางปฏิบัติที่ดีที่สุด: แนะนำให้ใช้เลเยอร์ DTO (Data Transfer Object) ไม่ว่าฐานข้อมูลที่อยู่เบื้องหลังจะถูกตั้งชื่ออย่างไร คุณควรกำหนดสัญญา API (DTO) ที่เป็นอิสระ เมื่อคุณกำลังกำหนด DTO แล้ว ทำไมไม่กำหนดให้เป็น camelCase เพื่อให้สอดคล้องกับมาตรฐานเว็บ? เครื่องมือแมปสมัยใหม่ (MapStruct, AutoMapper, Pydantic) สามารถจัดการการแปลงนี้ได้อย่างง่ายดาย

7. มองไปข้างหน้า: GraphQL และ gRPC

GraphQL: ชุมชนเกือบ 100% ยอมรับ camelCase หากทีมของคุณมีแผนจะนำ GraphQL มาใช้ในอนาคต การออกแบบ REST API ด้วย camelCase ตั้งแต่ตอนนี้ถือเป็นกลยุทธ์ "ความเข้ากันได้ไปข้างหน้า" (forward compatibility) ที่ชาญฉลาด

gRPC: มาตรฐาน Protobuf กำหนดไว้ว่า: ไฟล์ .proto ใช้ snake_case สำหรับการกำหนดฟิลด์ แต่ ต้อง ถูกแปลงเป็น camelCase เมื่อแมปไปยัง JSON นี่คือโซลูชันมาตรฐานของ Google สำหรับสภาพแวดล้อมที่มีหลายภาษา

8. สรุปและเมทริกซ์การตัดสินใจ

ไม่มีสิ่งที่ถูกหรือผิดอย่างสมบูรณ์ มีแต่การแลกเปลี่ยน (trade-offs) นี่คือกรอบการตัดสินใจสุดท้าย:

ข้อแนะนำ: ใช้ camelCase เป็นค่าเริ่มต้น

สำหรับ RESTful API ใหม่ส่วนใหญ่ที่มีวัตถุประสงค์ทั่วไปซึ่งให้บริการแก่ไคลเอนต์ Web/App นั้น แนะนำอย่างยิ่งให้ใช้ camelCase

เหตุผล: เพื่อให้สอดคล้องกับการครอบงำของ JSON/JavaScript/TypeScript และยอมรับพฤติกรรมของผู้ใช้งานส่วนใหญ่ถึง 90%

เครื่องมือ: ได้รับการสนับสนุนที่ดีที่สุดจาก OpenAPI code generators, Swagger UI และ IDE สมัยใหม่

ควรใช้ snake_case เมื่อใด?

• 1. ผู้ใช้งานเฉพาะกลุ่ม: ผู้ใช้งานหลักของ API คือนักวิทยาศาสตร์ข้อมูล Python หรือผู้ดูแลระบบ (System Ops) ที่ใช้ Curl/Bash
• 2. ระบบเดิม (Legacy Systems): API ที่มีอยู่แล้วใช้ snake_case ความสอดคล้องสำคัญกว่าแนวทางปฏิบัติที่ดีที่สุด (Consistency > Best Practice) อย่าผสมผสานรูปแบบการเขียนโค้ดในระบบเดียวกัน
• 3. เน้นความเร็วในการพัฒนาแบ็กเอนด์อย่างมาก: ใช้ Python/Ruby โดยไม่มีทรัพยากรในการบำรุงรักษาเลเยอร์ DTO และส่งผ่านโมเดลฐานข้อมูลโดยตรง

ตารางการตัดสินใจ

แก่นแท้ของการออกแบบ API คือ ความเห็นอกเห็นใจ ในบริบทของ Web API การห่อหุ้มความซับซ้อนไว้ในแบ็กเอนด์ (การจัดการการแมป) และมอบความสะดวกสบายให้กับผู้ใช้งาน (การปฏิบัติตามพฤติกรรมของ JS) คือทางเลือกที่สะท้อนถึงความเป็นมืออาชีพที่สูงกว่า