REST vs SOAP vs GraphQL vs gRPC — เลือกตัวไหนให้เหมาะกับงาน

มีคำถามหนึ่งที่โผล่มาในเกือบทุกโปรเจกต์ตอนเริ่มออกแบบระบบ — “เราจะให้ frontend คุยกับ backend ยังไงดี” หรือ “service สองตัวนี้จะส่งข้อมูลหากันแบบไหน”

แล้วพอไปหาคำตอบ ก็จะเจอชื่อสี่ตัวลอยมาพร้อมกัน: REST, SOAP, GraphQL, gRPC บางคนเชียร์ตัวนี้ บางคนบอกตัวนั้นตกยุคแล้ว สุดท้ายงงกว่าเดิม

ปัญหาคือคนชอบเอาทั้งสี่ตัวมาเรียงเทียบกันเหมือนเป็นของชนิดเดียวกัน ทั้งที่จริง ๆ แล้วทั้งสี่ตัวอยู่คนละหมวดหมู่กันด้วยซ้ำ การจะเลือกถูก ต้องเข้าใจก่อนว่าแต่ละตัวอยู่คนละประเภทกันยังไง

มาดูกันทีละตัวว่าแต่ละตัวคืออะไร เหมาะกับงานแบบไหน และเมื่อไหร่ที่ไม่ควรเอามาใช้

⚠️ เรื่องแรกที่ต้องเคลียร์ก่อน — ทั้งสี่ตัวไม่ใช่ของชนิดเดียวกัน#

ก่อนจะเทียบ ต้องรู้ก่อนว่าเรากำลังเทียบอะไรกับอะไร เพราะถ้าไม่เคลียร์ตรงนี้จะเข้าใจผิดตั้งแต่ต้น

• REST เป็น architectural style (รูปแบบสถาปัตยกรรม) — เป็นชุดของหลักการ ไม่ใช่ protocol หรือ tool ที่ลงไปติดตั้งได้
• SOAP เป็น protocol — โปรโตคอลรับส่งข้อความที่มีกฎตายตัวว่าหน้าตา message ต้องเป็นยังไง
• GraphQL เป็น query language + runtime — ภาษาสำหรับถามข้อมูล บวกกับตัวประมวลผลฝั่ง server
• gRPC เป็น framework — เฟรมเวิร์กสำหรับเรียกฟังก์ชันข้ามเครื่อง (RPC)

พูดง่าย ๆ คือ REST เป็น “แนวคิด” ส่วนอีกสามตัวเป็น “ของจริงที่จับต้องได้” คนละระดับกัน ดังนั้นเวลาเทียบ เราไม่ได้เทียบว่า “อันไหนดีกว่า” แบบตรง ๆ แต่เทียบว่า “งานแบบนี้ ควรหยิบตัวไหนมาใช้”

🌐 REST — ตัวมาตรฐานที่เริ่มก่อนได้เลย#

REST (Representational State Transfer) คือชุดหลักการที่ออกแบบมาให้ทำงานคู่กับเว็บโดยตรง ใช้กลไกของ HTTP เป็นพื้นฐาน พูดได้ว่า REST เกิดมาคู่กับเว็บ

หัวใจของ REST คือการมองทุกอย่างเป็น resource ที่ระบุได้ด้วย URL แล้วใช้ HTTP method มาตรฐาน (GET, POST, PUT, DELETE) จัดการกับ resource เหล่านั้น ข้อมูลส่งกันด้วย JSON เป็นหลัก ซึ่งทั้งคนและเครื่องอ่านง่าย

REST มีหลักการพื้นฐานหลายข้อ เช่น ต้องเป็น stateless (server ไม่เก็บ state ของ session แต่ละครั้ง) และ cacheable (ออกแบบให้ cache ได้) ซึ่งสองข้อนี้แหละที่ทำให้ REST scale ได้ดีและเข้ากับโครงสร้างเว็บได้อย่างเป็นธรรมชาติ

ข้อดี:

• ง่ายและเข้าใจง่ายที่สุดในสี่ตัว learning curve ต่ำ
• รองรับแทบทุกภาษา ทุก framework ทุก cloud provider และเบราว์เซอร์เรียกได้เลยโดยไม่ต้องลง library พิเศษ
• มี HTTP caching ในตัว และมี ecosystem อย่าง OpenAPI ช่วยทำ documentation

ข้อเสีย:

• ปัญหาคลาสสิกคือ over-fetching (ได้ข้อมูลมาเกินที่ต้องการ) และ under-fetching (ได้ไม่พอ ต้องยิงหลายครั้ง) เช่นอยากได้แค่ชื่อผู้ใช้ แต่ API ส่งมาทั้งก้อน หรืออยากได้ข้อมูลผู้ใช้พร้อมโพสต์ ต้องยิงสองรอบ

เมื่อไหร่ควรใช้: เป็นตัวเลือกเริ่มต้นที่ดีสำหรับ public API ทั่วไป และงานที่ต้องให้ client หลากหลายชนิดเข้าถึงได้ ถ้ายังไม่แน่ใจว่าจะใช้อะไร เริ่มที่ REST แทบจะไม่ผิด

📜 SOAP — รุ่นเก๋าที่ยังไม่ตายในวงการเฉพาะทาง#

SOAP เป็น protocol แบบ XML ล้วน — ทุก message ถูกห่อด้วย XML ก่อนส่งออกไป

จุดเด่นของ SOAP คือความเป็นทางการ มี WSDL เป็น contract ที่ระบุชัดเจนว่า service มีอะไรบ้าง รับ-ส่งอะไร และมีชุดมาตรฐาน WS-* ที่จัดการเรื่องหิน ๆ ได้ เช่น WS-Security (เข้ารหัสและเซ็นลายเซ็นระดับ message), WS-ReliableMessaging (รับประกันว่าข้อความถึงปลายทางแม้เน็ตล่ม) และ WS-AtomicTransaction (รองรับ transaction แบบ ACID ที่ rollback ได้ทั้งชุด)

ข้อดี:

• contract แข็งแรงและเป็นทางการมาก เหมาะกับระบบที่ผิดพลาดไม่ได้
• มาตรฐานด้าน security, reliability และ transaction ในตัว ครบเครื่อง
• ตรวจสอบย้อนหลังได้ดี

ข้อเสีย:

• XML ทำให้ข้อมูลแต่ละก้อน (payload) ใหญ่และหนัก กิน bandwidth สูง
• รองรับแค่ XML เท่านั้น และต้องเรียนรู้ WS-* ที่ค่อนข้างซับซ้อน ทำให้พัฒนาช้าลง
• โดยรวมเทอะทะและยุ่งยากกว่าอีกสามตัวมาก

เมื่อไหร่ควรใช้: ยังเป็นตัวเลือกที่มีเหตุผลในวงการที่มีมาตรฐานเข้มงวดและเปลี่ยนช้า เช่น ธนาคาร ระบบจ่ายเงิน สาธารณสุข (HIPAA, HL7) และงานราชการ แต่สำหรับโปรเจกต์ใหม่ทั่วไป คนส่วนใหญ่ไม่เลือก SOAP แล้ว

🔮 GraphQL — ขอข้อมูลได้เป๊ะตามที่ต้องการ#

GraphQL ถูกสร้างขึ้นมาเพื่อแก้ปัญหาของ mobile app ที่ต้องดึงข้อมูลซับซ้อน

แนวคิดหลักคือ client เป็นคนบอกเองว่าอยากได้ field อะไรบ้าง แทนที่ server จะเป็นคนกำหนดให้ตายตัวเหมือน REST ตัวอย่างที่เห็นภาพชัดคือ query เดียวสามารถดึง “ชื่อ เมืองหลวง และภาษา ของทุกประเทศในยุโรปที่ใช้สกุลเงิน Danish Krone” ได้ในครั้งเดียว ซึ่งถ้าเป็น REST อาจต้องยิงหลายรอบ

นี่คือคำตอบโดยตรงต่อปัญหา over/under-fetching ของ REST — ขอเท่าที่ใช้ ไม่ขาดไม่เกิน ผ่าน endpoint เดียว และมี schema แบบ strongly-typed ที่ตรวจสอบตัวเองได้ จึง self-documenting ในตัว

ข้อดี:

• ดึงเฉพาะข้อมูลที่ต้องการ ลด over-fetching ได้จริง
• schema แข็งแรง ยืดหยุ่นต่อ frontend หลายแบบ เหมาะกับ mobile

ข้อเสีย:

• caching ยาก เพราะ query ส่วนใหญ่ใช้ POST ซึ่งไม่ cache โดย default และถ้าพยายามใช้ GET เพื่อให้ cache ได้ query string อาจยาวเกินขีดจำกัด URL จนเจอ error ใน production
• เสี่ยงปัญหา N+1 — request แรกนำไปสู่อีก N requests เพื่อ resolve แต่ละ field ต้องแก้ด้วยเทคนิค batching อย่าง DataLoader
• ถ้า client ขอ field ซ้อนลึกเกินไป server อาจรับโหลดไม่ไหวจนล่มได้
• ติดตามปัญหาด้าน performance ยากกว่า เพราะทุก query วิ่งผ่าน /graphql เดียว หาจุดคอขวดลำบาก

ในทางปฏิบัติ ทีมจำนวนไม่น้อยเจอปัญหา caching และ N+1 กับ GraphQL ดังนั้นถ้าจะใช้ ต้องวางแผนเรื่อง performance ตั้งแต่ต้น

เมื่อไหร่ควรใช้: เหมาะกับ schema ที่ซับซ้อนและมีความสัมพันธ์เยอะ มี client หลายชนิดที่ต้องการข้อมูลต่างกัน หรืองาน mobile ที่อยากประหยัดปริมาณข้อมูลที่รับ-ส่ง

⚡ gRPC — เร็วและแน่น สำหรับให้ service คุยกันเอง#

gRPC เป็น RPC framework จุดต่างจากตัวอื่นคือใช้ HTTP/2 เป็น transport และใช้ Protocol Buffers (protobuf) แทน JSON

วิธีทำงานคือเรานิยาม service ในไฟล์ .proto ก่อน เช่น

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

จากนั้นใช้ตัว compiler ชื่อ protoc generate code ออกมาเป็นภาษาที่เราใช้ ความเจ๋งคือ gRPC รองรับภาษาเยอะมาก (Go, Python, Java, C#, Rust, Node และอีกหลายตัว) แล้ว server ที่เขียนด้วยภาษาหนึ่ง สามารถคุยกับ client อีกภาษาหนึ่งได้ ผ่าน proto contract เดียวกัน เพราะ contract ไม่ผูกกับภาษาใดภาษาหนึ่งโดยเฉพาะ

ข้อดี:

• เร็วมาก — protobuf เป็น binary ที่เล็กกว่า JSON หลายเท่า บวก HTTP/2 ทำให้ความล่าช้า (latency) ต่ำและรับโหลดได้สูง
• รองรับ bidirectional streaming เหมาะกับ microservices
• strong typing ข้ามภาษา ลด error และ contract ชัดเจน

ข้อเสีย:

• เบราว์เซอร์ไม่รองรับ gRPC แบบ native ต้องใช้ gRPC-Web เป็นตัวแปลงคั่นกลาง ซึ่งเพิ่มความซับซ้อน
• เป็น binary จึงอ่านไม่ออกด้วยตาเปล่า debug ยากถ้าไม่มีเครื่องมือเฉพาะ
• learning curve สูงกว่า REST และต้องรับ ecosystem เครื่องมือใหม่เข้ามา

เมื่อไหร่ควรใช้: เหมาะที่สุดกับ internal communication ระหว่าง microservices ที่ต้องการประสิทธิภาพสูงและ contract แน่น โดยเฉพาะใน Kubernetes cluster หลายองค์กรใช้ gRPC เป็นมาตรฐานสำหรับการสื่อสารภายในระหว่าง service

เมื่อไหร่ไม่ควรใช้: การเอา gRPC ไปทำ public-facing API ที่ต้องให้ client หลากหลาย (รวมเบราว์เซอร์) เรียกได้ ถือเป็น anti-pattern เพราะ gRPC ไม่ได้ออกแบบมาเพื่อสิ่งนั้น

🧭 แล้วในงานจริงเขาเลือกยังไง#

ความจริงที่หลายคนค้นพบคือ ไม่มีตัวไหนชนะทุกสนาม ทีมใหญ่ ๆ จึงไม่ได้เลือกแค่ตัวเดียว แต่ผสมกันตามจุดที่เหมาะ

ตัวอย่างที่เห็นชัดคือการเริ่มจาก REST แล้วเจอปัญหา over-fetching และความล่าช้าจากการยิง request หลายรอบ จึงนำ GraphQL มาเป็นชั้นกลางระหว่าง frontend กับ backend สำหรับ client หลายชนิด และใช้ gRPC สำหรับ internal API บางส่วน

รูปแบบที่นิยมในวงการจึงหน้าตาประมาณนี้:

• gRPC สำหรับการคุยกันภายในระหว่าง microservices (เน้นเร็วและแน่น)
• REST สำหรับ public API ที่ใคร ๆ ก็เรียกได้
• GraphQL สำหรับ frontend ที่ต้องการความยืดหยุ่นในการดึงข้อมูล
• SOAP เหลือไว้ในระบบ legacy หรือวงการที่ต้องการ contract และ security เข้มงวดเป็นพิเศษ

สรุปสั้น ๆ ว่าควรเริ่มมองตัวไหน:

🚀 ก้าวต่อไป#

ถ้าจะให้สรุปเป็นประโยคเดียว — อย่าเริ่มจากคำถามว่า “ตัวไหนดีที่สุด” แต่ให้เริ่มจากคำถามว่า “งานของเราหน้าตาเป็นยังไง” ใครคุยกับใคร ข้อมูลซับซ้อนแค่ไหน ต้องการความเร็วระดับไหน ต้องให้เบราว์เซอร์เรียกได้ไหม คำตอบของคำถามเหล่านี้จะชี้ตัวเลือกให้เองโดยอัตโนมัติ

และถ้าทั้งสี่ตัวยังตอบโจทย์ไม่ตรง ก็มีทางเลือกอื่น ๆ ให้ลองศึกษาเพิ่ม เช่น tRPC (TypeScript ล้วนแบบ end-to-end type-safe ไม่ต้อง codegen), Connect-RPC (gRPC ที่รองรับเบราว์เซอร์ได้โดยไม่ต้องใช้ proxy), WebSockets (real-time สองทาง) หรือฝั่ง event-driven อย่าง Webhooks และ AsyncAPI/Kafka

จุดเริ่มที่ดีที่สุดสำหรับคนเพิ่งเริ่มยังคงเป็น REST — เข้าใจง่าย ใช้ได้กว้าง แล้วค่อยขยับไปตัวอื่นเมื่อเจอข้อจำกัดจริง ๆ ในงานของตัวเอง เพราะสุดท้ายแล้วเครื่องมือที่ดีที่สุด คือเครื่องมือที่เหมาะกับปัญหาตรงหน้านั่นเอง

😎 ☕