Werner Vogels – 6 บทเรียนที่ได้เรียนรู้เพื่อการออกแบบ API ที่ดี
(aws.amazon.com)- บันทึกเกี่ยวกับ "6 หลักการในการสร้าง API ที่ดีที่ AWS เรียนรู้ตลอด 15 ปี"
-
API อยู่ตลอดไป!
-
โปรดรักษาความเข้ากันได้แบบย้อนหลัง
-
สร้างโดยย้อนกลับจากกรณีการใช้งานของลูกค้า
-
สร้าง API ที่ระบุข้อผิดพลาดอย่างชัดเจน
-
สร้าง API ที่เข้าใจจุดประสงค์และวิธีใช้งานได้ทันที
-
ใส่ใจไม่ให้รายละเอียดการติดตั้งใช้งานรั่วไหลออกมา
-
สิ่งที่มักพลาดในการออกแบบ API ระยะแรก
-
การสร้าง API ที่ขยายต่อได้สูงด้วย Smithy
4 ความคิดเห็น
สำหรับผม ข้อ 5 โดนใจที่สุดครับ
ผมเคยดู "แบบนี้เป็น REST API ที่โอเคหรือเปล่า" ที่อ้างอิงไว้มาก่อน แล้วรู้สึกว่าดีมากครับ: https://tv.naver.com/v/2292653
ปกติผมไม่ได้ใส่ใจกับข้อมูลเชิง semantic แบบนี้นัก แต่พอดู Github API ก็เห็นว่ามีการส่งข้อมูลลักษณะนี้กลับมาได้ดี เลยทำให้รู้สึกว่าออกแบบมาได้ดีครับ
ดูเหมือนจะเป็นเนื้อหาที่ดีครับ
โดยเฉพาะข้อ 1 และ 4 น่าจะเป็นประเด็นที่มักจะพูดถึงกันเสมอเวลาทำรีวิว
ข้อ 3 ดูเหมือนจะเชื่อมโยงกับสิ่งที่ Joshua Bloch เคยพูดไว้ว่า "Write to Your API Early and Often" (https://www.youtube.com/watch?v=aAb7hSCtvGw)
พอจัดเรียงไว้แบบนี้ก็ดูเหมือนเป็นเรื่องที่ชัดเจนอยู่แล้ว แต่พอทำจริงก็รู้สึกว่าเป็นสิ่งที่เผลอทำพลาดซ้ำแล้วซ้ำเล่า