ใช้ POST เท่านั้น? มายุติการถกเถียงการออกแบบ API อันไร้สาระนี้กันเถอะ

เมื่อเร็ว ๆ นี้มีการสนทนาเกี่ยวกับการที่จะออกแบบ APIs โดยใช้ "POST เท่านั้น" ซึ่งดึงดูดความสนใจของฉัน หลังจากดิ่งลึกลงไปในข้อถกเถียงนี้ ฉันพบว่าปัญหาที่คนถกเถียงกันนั้นไม่เพียงแต่ไม่มีความหมาย แต่มันยังเผยให้เห็นถึงความเข้าใจผิดของนักพัฒนาหลายคนเกี่ยวกับแก่นแท้ของการออกแบบ API วันนี้มาลงลึกในแนวคิดหลักของการออกแบบ API และดูกันว่าทำไมข้อถกเถียงนี้ไม่ควรมีตั้งแต่ต้น

ความเข้าใจผิดของ "ใช้ POST เท่านั้น"#

นักพัฒนาที่สนับสนุนการใช้ "POST เท่านั้น" แทนที่จะเป็นข้อกำหนดของ RESTful API ชัดเจนว่าไม่ได้จับจุดสำคัญที่สุดของการออกแบบ API ข้อเสนอของพวกเขามักจะรวมถึง:

1. ทำให้การออกแบบง่ายขึ้น: วิธีเดียวจัดการทุกอย่าง
2. ความปลอดภัย: พารามิเตอร์ POST ไม่ปรากฏใน URL
3. ความยืดหยุ่น: POST สามารถส่งโครงสร้างข้อมูลใดก็ได้

เมื่อดูเผิน ๆ ข้อโต้แย้งเหล่านี้ดูเหมือนจะมีเหตุผล แต่ในความเป็นจริงมุมมองนี้สับสนระหว่างการเลือกใช้ HTTP methods กับสไตล์การออกแบบ API ซึ่งเป็นคำถามในระดับที่ต่างกัน POST เป็นเพียงหนึ่งในวิธีของ HTTP protocol ในขณะที่ REST เป็นสไตล์ของการออกแบบ API

แก่นแท้ของการออกแบบ API#

ก่อนที่จะสนทนาเกี่ยวกับสไตล์ API เฉพาะ เราจำเป็นต้องเข้าใจวัตถุประสงค์หลักของการออกแบบ API คืออะไร API ที่ดีควร:

1. ชัดเจนและเข้าใจได้: นักพัฒนาคนอื่น ๆ (รวมถึงตนเองในอนาคต) ควรจะเข้าใจวัตถุประสงค์ของแต่ละ endpoint ได้อย่างตรงไปตรงมา
2. มีความสม่ำเสมอ: ทำตามข้อกำหนดบางอย่างเพื่อลดต้นทุนการเรียนรู้
3. ขยายขอบเขตได้: สามารถควบคุมเวอร์ชันและขยายฟังก์ชั่นได้ง่าย
4. มีประสิทธิภาพ: คำนึงถึงประสิทธิภาพในแง่ของการใช้งานและการใช้ทรัพยากร

RESTful API: ไม่ใช่แค่การเลือกใช้ HTTP methods เท่านั้น#

RESTful API เป็นเพียงหนึ่งในหลาย ๆ สไตล์การออกแบบ API ที่เน้นที่ทรัพยากรและปฏิบัติการบนทรัพยากร ลองดูตัวอย่างระบบบล็อกง่าย ๆ เพื่อดูว่าการออกแบบ RESTful API เป็นอย่างไร:

1. นำบทความทั้งหมด:

2. นำบทความเฉพาะ:

3. สร้างบทความใหม่:

4. อัปเดตบทความ:

5. ลบบทความ:

ในตัวอย่างนี้เราเห็นว่า:

• API ถูกออกแบบโดยยึดตามทรัพยากร "บทความ"
• ใช้ HTTP methods ต่าง ๆ เพื่อเป็นตัวแทนของปฏิบัติการต่าง ๆ
• โครงสร้าง URL ชัดเจนบ่งบอกถึงทรัพยากรที่ถูกปฏิบัติการ

วิธีการออกแบบนี้ทำให้ API เป็นแบบ intuitive และ self-explanatory ทำให้นักพัฒนาสามารถเข้าใจหน้าที่ของแต่ละ endpoint ได้ง่าย

RPC: การเข้าใจสไตล์ API ที่อยู่เบื้องหลัง "POST เท่านั้น"#

เป้าหมายของสไตล์การออกแบบ API แบบ RPC (Remote Procedure Call) คือการทำให้การเรียกใช้บริการระยะไกลง่ายเหมือนกับการเรียกใช้ฟังก์ชันในเครื่อง

น่าสนใจ คำที่สนับสนุนการ "POST เท่านั้น" อาจไม่รู้ว่าจริง ๆ แล้วพวกเขากำลังบรรยายสไตล์ของ RPC

เมื่อเทียบกับ RESTful APIs, RPC เน้นที่การปฏิบัติมากกว่าทรัพยากร นี่คือเหตุผลที่ APIs แบบ RPC มักใช้รูปแบบ "กริยา + นาม" เช่น getProduct(productId) หรือ createUser(userData)

ในหลาย ๆ การใช้งานของ RPC ปฏิบัติการทั้งหมดมักถูกส่งผ่าน POST requests ไปยัง endpoint เดียว โดยมีการปฏิบัติและพารามิเตอร์เฉพาะที่ระบุใน request body นี่คือเหตุผลว่าทำไมแนวคิด "POST เท่านั้น" จึงใกล้เคียงกับ RPC มากกว่า REST

เช่น คำขอ "นำสินค้า" แบบ RPC โดยอิง HTTP อาจดูเหมือนกับนี้:

เฟรมเวิร์ค RPC สมัยใหม่ เช่น gRPC ให้การใช้งานที่ทรงพลังและมีประสิทธิภาพมากขึ้น มาดูตัวอย่างนี้เพื่อแสดงสไตล์ RPC:

ก่อนอื่น เรากำหนดบริการและรูปแบบข้อความ (โดยใช้ Protocol Buffers):

จากนั้น การใช้บริการนี้ในไคลเอนต์ Node.js นั้นง่ายเหมือนการเรียกใช้ฟังก์ชันในเครื่อง:

ในตัวอย่างสไตล์ RPC นี้ เราเห็นว่า:

1. การกำหนดบริการแสดงรายการของปฏิบัติการทั้งหมดที่มีอย่างชัดเจน (ในตัวอย่างที่เรียบง่ายนี้ GetArticle และ CreateArticle)
2. แต่ละปฏิบัติมีประเภทของการร้องขอและการตอบกลับที่กำหนดไว้อย่างชัดเจน
3. โค้ดไคลเอนต์ดูเหมือนการเรียกใช้ฟังก์ชันอะซิงโครนัสในเครื่อง โดยใช้ await เพื่อรอผลลัพธ์ ซึ่งซ่อนความซับซ้อนของการสื่อสารเครือข่ายต่อไป
4. ไม่จำเป็นต้องสร้างคำขอ HTTP หรือวิเคราะห์คำตอบ JSON ด้วยตนเอง

แม้ว่าในชั้นล่างอาจยังคงใช้ HTTP/2 เป็นโปรโตคอลการส่งข้อมูล เฟรมเวิร์ค RPC (เช่น gRPC) ให้ layer ส่วน abstraction ที่ทำให้การเรียกทางไกลดูและรู้สึกเหมือนการเรียกฟังก์ชันในเครื่อง

ดังนั้น เราจะเห็นว่าการโต้แย้งส่วนใหญ่เกี่ยวกับ "POST เท่านั้น" และ RESTful APIs นั้นควรจะเป็นการสนทนาเกี่ยวกับสไตล์ API สองแบบนี้: REST และ RPC อย่างไรก็ตาม สิ่งสำคัญคือต้องตระหนักว่าสองสไตล์นี้แต่ละสไตล์มีสถานการณ์ที่ใช้เฉพาะของตัวเอง และการเลือกควรพิจารณาจากความต้องการเฉพาะของโครงการ ไม่ใช่การอภิรมย์ส่วนตัว

REST vs RPC: ไม่มีความเหนือกว่าหรือด้อยกว่าอย่างแท้จริง#

ตอนนี้เรารู้ถึงความแตกต่างระหว่าง REST และ RPC ลองมาดูสถานการณ์ที่ใช้แต่ละแบบกัน:

1. REST เหมาะสำหรับ:
   • แอปพลิเคชันที่ยึดตามทรัพยากร (เช่น ระบบการจัดการเนื้อหา แพลตฟอร์มบล็อก เว็บไซต์อีคอมเมิร์ซ)
   • สถานการณ์ที่ต้องการการสนับสนุนการแคชที่ดี (คำร้อง GET สามารถแคชได้ตามธรรมชาติ)
   • โครงการที่ต้องการใช้ประโยชน์จาก semantics ของ HTTP (เช่น การใช้สถานะโค้ดที่เหมาะสม)
   • APIs ที่ต้องการการค้นพบที่ดีและการอธิบายตนเองสำหรับผู้ใช้งานสาธารณะ
2. RPC เหมาะสำหรับ:
   • แอปพลิเคชันที่ยึดตามการปฏิบัติการ (เช่น การประมวลผลข้อมูลที่ซับซ้อน การควบคุมการทำงาน)
   • ระบบที่ต้องการประสิทธิภาพสูงและความหน่วงต่ำ (เช่น ระบบการซื้อขายแบบเรียลไทม์)
   • การสื่อสารระหว่างไมโครเซอร์วิสภายใน (ซึ่งอาจต้องการการส่งพารามิเตอร์ที่ยืดหยุ่นมากขึ้น)
   • เมื่อการปฏิบัติการไม่สามารถ map ไปยัง CRUD (สร้าง อ่าน อัปเดต ลบ) แบบง่ายๆ ได้

การเลือกสไตล์ควรเป็นไปตามความต้องการเฉพาะของคุณ ในบางกรณี คุณอาจใช้สไตล์สองแบบนี้ผสมกันภายในระบบเดียวกันเพื่อตอบสนองความต้องการของส่วนต่างๆ

บทสรุป#

1. แก่นของการออกแบบ API คือความชัดเจน สม่ำเสมอ ขยายขอบเขตได้ และมีประสิทธิภาพ ไม่ใช่อยู่ที่การยึดติดกับวิธีหรือสไตล์ใดสไตล์หนึ่ง
2. ทั้ง RESTful และ RPC เป็นแบบอย่างการออกแบบ API ที่เป็นที่รู้จัก การเลือกมีควรขึ้นอยู่กับความต้องการของโครงการ ไม่ใช่จากความชอบส่วนตัว
3. หากคุณตัดสินใจใช้ "POST เท่านั้น" กรุณาออกแบบ API ของคุณตามสไตล์ RPC เหมือนกับ RESTful มันเป็นข้อกำหนด API ที่ใช้กันทั่วไปในวงการ แต่มันควรถูกใช้ในสถานการณ์ที่เหมาะสม
4. อย่าสับสนกับรายละเอียดทางเทคนิคเบื้องต้น สิ่งที่สำคัญจริง ๆ คือว่า API ของคุณสามารถให้บริการผู้ใช้ของคุณและตอบสนองความต้องการทางธุรกิจของคุณได้อย่างมีประสิทธิภาพหรือไม่
5. เมื่อออกแบบ API ให้ใช้เวลาไปกับการคิดเกี่ยวกับโครงสร้างทรัพยากรของคุณ, ตรรกะทางธุรกิจ และความต้องการของผู้ใช้ มากกว่าไปยึดติดกับว่าควรใช้ HTTP method ใด

มามุ่งเน้นไปที่การออกแบบ API ที่ยอดเยี่ยมอย่างแท้จริงกันเถอะ ท้ายที่สุด เทคโนโลยีมีไว้เพื่อแก้ปัญหา ไม่ได้มีไว้เพื่อสร้างมันขึ้นมา