REST กับ RPC กับ GraphQL

REST เป็นวิธีหนึ่งในการสร้าง API ไม่ใช่วิธีเดียว การรู้จักทางเลือกอื่นช่วยลับความรู้สึกของคุณให้คมขึ้นว่าเมื่อไร REST คือเครื่องมือที่เหมาะสม

สามรูปแบบ

REST จัดระเบียบ API รอบ ๆ resource (คำนาม) ที่คุณกระทำต่อด้วย HTTP method มาตรฐาน จุดแข็ง: ได้ caching ฟรี ๆ มี uniform interface และเหมาะอย่างยิ่งกับ domain แบบ CRUD และ public API จุดอ่อน: บางครั้ง client เกิด over-fetch (ได้ field มากกว่าที่ต้องการ) หรือ under-fetch (ต้องไป-กลับหลายรอบ)
RPC จัดระเบียบ API รอบ ๆ procedure (คำกริยา) — คุณเรียก operation ที่มีชื่อ เช่น createUser หรือ sendEmail โดยมักผ่าน HTTP POST หรือ gRPC จุดแข็ง: เหมาะตามธรรมชาติกับ API ที่เน้น action และการเรียกระหว่าง service ภายในด้วยกัน จุดอ่อน: ความเป็นมาตรฐานน้อยกว่า, HTTP caching อ่อนแอกว่า และพื้นผิวของ API โตขึ้นทุกครั้งที่มีคำกริยาใหม่
GraphQL เปิดเผย endpoint เดียวและ query language: client ขอ field ที่ต้องการมาอย่างแม่นยำ จุดแข็ง: ไม่มี over/under-fetching, ไป-กลับรอบเดียวสำหรับหน้าจอที่ซับซ้อน จุดอ่อน: HTTP caching ทำได้ยากกว่า และ server ต้องป้องกัน query ที่มีต้นทุนสูง

flowchart TD
  Need{What does the client need?} --> CRUD[Resource CRUD, public API, caching]
  Need --> Action[Action-oriented, internal services]
  Need --> Flexible[Flexible field selection, many clients]
  CRUD --> REST
  Action --> RPC
  Flexible --> GraphQL

จับคู่รูปแบบให้ตรงกับสิ่งที่ client ต้องการจริง ๆ

การเลือก

เลือกใช้ REST เมื่อ domain ของคุณมีรูปร่างเป็น resource ตามธรรมชาติ คุณต้องการ HTTP caching และ public contract ที่คนเข้าใจกันอย่างกว้างขวาง และ CRUD บวกกับ action อีกไม่กี่อย่างก็ครอบคลุม use case ได้ — ซึ่งก็คือ back end ของเว็บและมือถือส่วนใหญ่ เลือกใช้ RPC/gRPC สำหรับการเรียก service ภายในที่มี throughput สูง เลือกใช้ GraphQL เมื่อ client ที่แตกต่างกันจำนวนมากต้องการข้อมูลคนละส่วนจาก data graph ที่อุดมและเชื่อมโยงกัน

Style	ข้อดี	ข้อเสีย	เหมาะกับ
REST	มาตรฐาน, cacheable, ง่าย debug	over/under-fetching	Public API, CRUD resource
GraphQL	ดึงเฉพาะที่ต้องการ, flexible	caching ยาก, complex	หลาย client ต้องการ data ต่างกัน
gRPC	เร็ว, type-safe, streaming	ไม่ human-readable, tooling มาก	Microservice internal, high performance
JSON-RPC	เรียบง่าย	tight coupling, ไม่มี standard URL	Internal tool, simple integration

ข้อผิดพลาดที่พบบ่อย

เลือก GraphQL เพราะ Hype อาการ:

API มี client เดียวที่ต้องการข้อมูลชุดเดียว
ใช้ GraphQL แต่ complexity เพิ่มโดยไม่ได้ benefit
REST เหมาะกว่าเมื่อ use case ตรงไปตรงมา

ใช้ REST สำหรับ Internal Microservice ที่ต้องการ Performance อาการ:

service เรียกกัน 100 ครั้งต่อ request — HTTP overhead สะสม
gRPC หรือ message queue เหมาะกว่าสำหรับ internal high-frequency call

💡 ตัวอย่างจากของจริง

GitHub:

มีทั้ง REST API v3 และ GraphQL API v4

REST สำหรับ simple operation, GraphQL สำหรับ complex query ที่ต้องการ data หลาย resource

Netflix:

ใช้ gRPC สำหรับ microservice internal call

REST สำหรับ public-facing API ที่ partner และ third-party ใช้