หลังจากแบ่งปันความรู้เรื่องการพัฒนา RESTful API ด้วย
Spring Boot, NodeJS และ Go ใน 3 วันไป
จึงทำการสรุปแนวคิด แนวปฏิบัติ
ที่ไม่ว่าจะพัฒนาด้วยภาษา หรือ framework ใด ๆ
ก็สามารถใช้งานร่วมกันได้
มาดูกันว่ามีอะไรบ้าง ?
เรื่องแรกการออกแบบตามแนวทางของ REST
น่าจะเป็นเรื่องที่ยากที่สุดแล้ว
ควรต้องออกแบบเป็น resource-centric endpoint มากกว่า
แต่ยังคงมีแนวทางที่ใช้กันมาอย่างยาวนาน
เช่นรูปแบบในการตั้งชื่อ endpoint หรือ URI ต่าง ๆ เช่น
- POST inquirySomething สำหรับดึงข้อมูล
- POST createSomething สำหรับสร้างข้อมูล
ไม่เป็นไร !!
แต่ส่งที่ให้ความสนใจมากกว่าคือ
- การออกแบบควรออกแบบให้ตรงกับความต้องการของผู้ใช้งาน มากกว่าการ reuse
- จัดการ response code ให้ดี แต่ส่วนใหญ่จะเป็น 200 only เพราะว่า ทาง operation หรือ devops บอกมาอีกที
- เรื่อง request/response ให้เหมือนกันทุก ๆ endpoint ก็แล้วกัน (มีมาตรฐานเดียวกัน ไม่ใช่แล้วแต่อารมณ์)
สิ่งที่แนะนำเพิ่มเติมคือเรื่องของเอกสาร เช่น Swagger หรือ OpenAPI นั้น
ควรใช้แนวคิด design/api first
มากกว่าให้ทำการ generate document หลังจากที่ code เสร็จแล้ว
ประเด็นคือ สิ่งที่ design และ สิ่งที่พัฒนามา มันตรงกันไหม ?
แยกเอกสารกันอีก !!
ลำบากไปไหม ?
เรื่องที่สอง Security-first ไว้ก่อน
เรื่องของความปลอดภัยของ API สำคัญมาก ๆ
แนะนำให้ศึกษาเรื่อง OWASP API Security Top 10 ก่อน
เพื่อให้ทีมมีความรู้ความเข้าใจเกี่ยวกับปัญหา หรือ รูปแบบการโจมตี
พร้อมกับสรุปแนวทางในการออกแบบ พัฒนา และ ทดสอบ ต่อไป
ไม่ว่าจะใช้ token-based ด้วย JWT (JSON Web Token)
หรือจะนำ OAuth มาใช้งานก็ว่าไป
ยังไม่พอเรื่องของการใช้งาน Rate limit และป้องกันการ DDOS ก็ต้องสนใจด้วยเสมอ
เรื่องที่สาม การจัดการ error ต่าง ๆ (Error handling)
อย่างแรกเรื่องของการสรุป error code, error format ที่ชัดเจน
เพื่อให้ทีมมีความเข้าใจร่วมกัน
คิดถึงคนใช้งานด้วย ว่า error เหล่านั้นมันเหมาะสมหรือไม่
อีกอย่างระวังการแสดง error ที่ชัดเจนเกินไปสำหรับ public API
มิเช่นนั้นจะมีปัญหาเรื่องของ security
แต่ถ้าเป็น private API ก็จัดได้เต็มที่
เรื่องที่สี่ การทดสอบ
เริ่มจากการ design test case ต่าง ๆ ให้ดีควรต้องทำตั้งแต่การ design API แล้ว
เพื่อให้เข้าใจว่าแต่ละ API นั้น จะต้องส่งมอบอย่างไรบ้าง
ทั้ง success และ failure case
และต้องสำพันธ์กับ feature ที่ส่งมอบด้วยนะ
การทดสอบมีทั้งทดสอบทั้งมุมมองจากคนภายนอกและภายใน เช่น
- ภายนอก (External หรือ Blackbox) จะสนใจเพียง request และ response เท่านั้น ว่าทำตามที่คาดหวังหรือไม่
- ภายใน (Internal หรือ Whitebox) จะให้ความสนใจกับ code ที่พัฒนาขึ้นมาว่าทำงานตามที่คาดหวังหรือไม่
ซึ่งควรต้องทำทั้งคู่ เพื่อเสริมสร้างความมั่นใจ
ไม่ว่าจะเป็น E2E, Integrate, Component, Contract และ Unit testing
ทุก ๆ ภาษา และ framework มีให้ใช้งานอยู่แล้ว
ขาดอย่างเดียวคือ คนนำไปใช้งานนั่นเอง
อย่าบอกว่า ไม่มีเวลาละ (แต่ดันมีเวลาแก้ bug)
เรื่องที่ห้า คือ observability ของ RESTful API
เป็นการดูพฤติกรรมการทำงานของ API ว่าทำงานตามที่เราคาดหวังหรือไม่
หรือถ้ามีปัญหาเกิดขึ้นมา
ระบบ observability นั้นช่วยชี้จุดเกิดปัญหา พร้อมรายละเอีดยที่ชัดเจนหรือไม่
โดยประกอบไปด้วย 5 ตัวหลักคือ
- Exception tracking เมื่อมีปัญหาขึ้นมาตรงไหน แจ้งทันที
- Application metric ทำการจัดเก็บข้อมูลตัวเลขต่าง ๆ ทั้งการใช้งานจากผู้ใช้งานและ การใช้งาน resource ต่าง ๆ ของต่ละ endpoint
- Distributed tracing ก็ว่าในระบบงานของเรามีการเรียกในแต่ละ hop อย่างไรบ้าง หรือ code เรียกใช้งานแต่ละ function อย่างไรบ้าง
- Centralized log ทำการจัดเก็บ log ของการทำงานในระบบ โดยควรเป็น structured log หรือ มีโครงสร้างและรูปแบบที่เป็นมาตรฐาน ไม่ใช่มาตรฐานของใครของมัน อีกอย่าง log เรามักจะดูเมื่อเกิดปัญหา ดังนั้นก็ควรแยก log ที่มีปัญหาออกมา น่าจะดีกว่าไหม !!
- สุดท้ายคือระบบ Alert นำข้อมูลจาก 3 ตัวบน เอามาวิเคราะห์หา pattern เพื่อแจ้งต่อไป
เรื่องที่หก คือ ส่วนเพิ่มเติม
- เรื่องของการทำ caching
- เรื่องของการทำ profiling และ benchmark
- เรื่องของการนำ Asynchronous communication/process เข้ามาช่วย
- เรื่องของการทำ CI/CD ของแต่ละ API
ดังนั้นลองดูกันว่า ในการพัฒนา RESTful API ของเรานั้น
ทำกันอย่างไรบ้าง ?
