REST​ ​API​ ​คือ​อะไร​:​ ​Frontend​ ​และ​ ​Backend​ ​ติดต่อ​กัน​อย่างไร

REST API มักหมายถึงบริการบน HTTP ที่ให้ Client เข้าถึง Resource เช่น คำขอ ผู้ใช้ หรือสินค้า ผ่าน URL และวิธีเรียกอย่าง GET หรือ POST คำว่า REST มีข้อกำหนดเชิงสถาปัตยกรรมมากกว่าการส่ง JSON ผ่าน HTTP เฉย ๆ แต่ในการคุยงานประจำวันคนมักเรียก HTTP API ลักษณะนี้ว่า REST API จึงควรตกลงสัญญาการใช้งานให้ชัดมากกว่าพึ่งชื่อ

หนึ่ง Request มีอะไร

Frontend ส่ง Method, URL, Header และ Body ตามความจำเป็น Backend ตอบ Status Code และข้อมูล เช่น GET /requests/123 เพื่ออ่านคำขอ หรือ POST /requests เพื่อสร้างใหม่ ผลสำเร็จและข้อผิดพลาดควรแยกชัด เช่น ไม่พบรายการ ไม่ผ่านสิทธิ์ หรือข้อมูลไม่ถูกต้อง เพราะ Frontend ต้องแสดงข้อความต่างกัน

ภาพที่ 1: สัญญา API ต้องระบุทั้งข้อมูลเข้า ผลสำเร็จ และผลผิดพลาดเพื่อให้สองทีมพัฒนาร่วมกันได้

ตัวอย่างสมมติ: ส่งคำขอ

ผู้ใช้กดส่งแบบฟอร์ม Frontend ส่งข้อมูลไปยัง POST /requests Backend ตรวจสิทธิ์และข้อมูล จากนั้นสร้างรายการและตอบรหัสคำขอ หากผู้ใช้ส่งซ้ำเพราะเครือข่ายช้า ทีมต้องกำหนดว่าจะป้องกันรายการซ้ำอย่างไร รายละเอียดนี้เป็นส่วนของสัญญา API ที่ชื่อ Endpoint อย่างเดียวตอบไม่ได้

ออกแบบให้ดูแลต่อได้

กำหนดชื่อ Resource ให้สม่ำเสมอ รูปแบบเวลาและตัวเลขที่ชัด การแบ่งหน้าเมื่อรายการมาก และรหัสข้อผิดพลาดที่ไม่เปิดข้อมูลลับ หาก API เปิดให้หลายระบบใช้ ควรมีเอกสารและตัวอย่างทดสอบ พร้อมวิธีจัดการเมื่อเปลี่ยนสัญญา ไม่ควรให้ Frontend เดาความหมายจากข้อความผิดพลาดที่เปลี่ยนได้

สำหรับรายงาน

แสดง Request–Response อย่างน้อยหนึ่งกรณีสำเร็จและหนึ่งกรณีผิดพลาด อธิบายว่าแต่ละ Field มาจากไหนและใครมีสิทธิ์เข้าถึง แยกคำว่า REST ตามข้อกำหนดจากการใช้คำเรียก HTTP API แบบทั่วไป เพื่อไม่สรุปว่าทุก API ที่ใช้ JSON เป็น RESTful โดยอัตโนมัติ

อ่าน REST กับ GraphQL และ Backend Development หรือดู บริการระบบหลังบ้านและ API

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ ตาราง Method, URL, Request Body, Status Code และ Response ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

เกณฑ์ประเมินตัวอย่างคือ ผู้เรียกใช้แยกสำเร็จ ผิดข้อมูล ไม่พบ และไม่มีสิทธิ์ได้ ส่วนข้อจำกัดที่ต้องระบุคือ ชื่อ endpoint เพียงอย่างเดียวไม่ทำให้ API ชัด ต้องกำหนดสัญญาข้อมูล หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน

แหล่งข้อมูลประกอบ

• MDN: REST — ข้อจำกัดเชิงสถาปัตยกรรมและการใช้คำทั่วไป
• MDN: HTTP methods — ความหมายของ Method หลัก