การเปิดโปงตำนาน "ใช้ POST เท่านั้น" ใน API อธิบายว่ามันเกิดจากความเข้าใจผิดเกี่ยวกับหลักการออกแบบ API และชี้แจงกรณีการใช้งานที่เหมาะสมสำหรับสไตล์การออกแบบ RESTful และ RPC
เมื่อเร็ว ๆ นี้มีการสนทนาเกี่ยวกับการที่จะออกแบบ APIs โดยใช้ "POST เท่านั้น" ซึ่งดึงดูดความสนใจของฉัน หลังจากดิ่งลึกลงไปในข้อถกเถียงนี้ ฉันพบว่าปัญหาที่คนถกเถียงกันนั้นไม่เพียงแต่ไม่มีความหมาย แต่มันยังเผยให้เห็นถึงความเข้าใจผิดของนักพัฒนาหลายคนเกี่ยวกับแก่นแท้ของการออกแบบ API วันนี้มาลงลึกในแนวคิดหลักของการออกแบบ API และดูกันว่าทำไมข้อถกเถียงนี้ไม่ควรมีตั้งแต่ต้น
นักพัฒนาที่สนับสนุนการใช้ "POST เท่านั้น" แทนที่จะเป็นข้อกำหนดของ RESTful API ชัดเจนว่าไม่ได้จับจุดสำคัญที่สุดของการออกแบบ API ข้อเสนอของพวกเขามักจะรวมถึง:
เมื่อดูเผิน ๆ ข้อโต้แย้งเหล่านี้ดูเหมือนจะมีเหตุผล แต่ในความเป็นจริงมุมมองนี้สับสนระหว่างการเลือกใช้ HTTP methods กับสไตล์การออกแบบ API ซึ่งเป็นคำถามในระดับที่ต่างกัน POST เป็นเพียงหนึ่งในวิธีของ HTTP protocol ในขณะที่ REST เป็นสไตล์ของการออกแบบ API
ก่อนที่จะสนทนาเกี่ยวกับสไตล์ API เฉพาะ เราจำเป็นต้องเข้าใจวัตถุประสงค์หลักของการออกแบบ API คืออะไร API ที่ดีควร:
RESTful API เป็นเพียงหนึ่งในหลาย ๆ สไตล์การออกแบบ API ที่เน้นที่ทรัพยากรและปฏิบัติการบนทรัพยากร ลองดูตัวอย่างระบบบล็อกง่าย ๆ เพื่อดูว่าการออกแบบ RESTful API เป็นอย่างไร:
นำบทความทั้งหมด:
นำบทความเฉพาะ:
สร้างบทความใหม่:
อัปเดตบทความ:
ลบบทความ:
ในตัวอย่างนี้เราเห็นว่า:
วิธีการออกแบบนี้ทำให้ API เป็นแบบ intuitive และ self-explanatory ทำให้นักพัฒนาสามารถเข้าใจหน้าที่ของแต่ละ endpoint ได้ง่าย
เป้าหมายของสไตล์การออกแบบ 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 นี้ เราเห็นว่า:
GetArticle และ CreateArticle)await เพื่อรอผลลัพธ์ ซึ่งซ่อนความซับซ้อนของการสื่อสารเครือข่ายต่อไปแม้ว่าในชั้นล่างอาจยังคงใช้ HTTP/2 เป็นโปรโตคอลการส่งข้อมูล เฟรมเวิร์ค RPC (เช่น gRPC) ให้ layer ส่วน abstraction ที่ทำให้การเรียกทางไกลดูและรู้สึกเหมือนการเรียกฟังก์ชันในเครื่อง
ดังนั้น เราจะเห็นว่าการโต้แย้งส่วนใหญ่เกี่ยวกับ "POST เท่านั้น" และ RESTful APIs นั้นควรจะเป็นการสนทนาเกี่ยวกับสไตล์ API สองแบบนี้: REST และ RPC อย่างไรก็ตาม สิ่งสำคัญคือต้องตระหนักว่าสองสไตล์นี้แต่ละสไตล์มีสถานการณ์ที่ใช้เฉพาะของตัวเอง และการเลือกควรพิจารณาจากความต้องการเฉพาะของโครงการ ไม่ใช่การอภิรมย์ส่วนตัว
ตอนนี้เรารู้ถึงความแตกต่างระหว่าง REST และ RPC ลองมาดูสถานการณ์ที่ใช้แต่ละแบบกัน:
การเลือกสไตล์ควรเป็นไปตามความต้องการเฉพาะของคุณ ในบางกรณี คุณอาจใช้สไตล์สองแบบนี้ผสมกันภายในระบบเดียวกันเพื่อตอบสนองความต้องการของส่วนต่างๆ
มามุ่งเน้นไปที่การออกแบบ API ที่ยอดเยี่ยมอย่างแท้จริงกันเถอะ ท้ายที่สุด เทคโนโลยีมีไว้เพื่อแก้ปัญหา ไม่ได้มีไว้เพื่อสร้างมันขึ้นมา