API คืออะไร ?
ถ้าพูดสั้นๆก็คือ “ข้อมูล” รูปแบบหนึ่งๆ ที่ทำออกมาเพื่อให้พร้อมนำไปใช้งานอาจแสดงออกมาได้หลายรูปแบบขึ้นอยู่กับความเหมาะสมกับการใช้งาน หรือผู้ที่จะนำไปใช้ รูปแบบที่นิยมใช้จะเป็นรูปแบบ xml หรือ Json ทั้งสองรูปแบบก็มีข้อดีข้อเสียต่างกัน แต่ปัจจุบันนิยมใช้ Json มากกว่า
ข้อดีของ XML :
เนื่องจากเป็นรูปแบบที่เกิดมาก่อนนานมาก และมีการกำหนดมาตรฐานที่ชัดเจน ทำให้ Tools ต่างๆของโปรแกรมสำเร็จรูปจะซัพพอร์ตรูปแบบนี้ เช่น excel หรือพวก Report ต่างๆ
ข้อดีของ Json :
เป็นรูปแบบที่คล้ายคลึงกับข้อมูลในการเขียนโปรแกรม ทำให้ใช้งานง่าย ภาษาคอมพิวเตอร์สมัยใหม่ส่วนใหญ่จะมี Library ให้สามารถนำไปเรียกใช้งานได้เลย
*หากเป็น XML อาจต้องเขียนโปรแกรมเพื่อแปลงค่าให้พร้อมใช้งานก่อน
ซึ่งภาษาใหม่ๆ จะนิยมใช้เป็น Json มากกว่าเนื่องจากไม่ต้องแปลงค่าทำให้รวดเร็วในการใช้งาน
ข้างบนที่เขียนมาเป็นพื้นฐานที่โปรแกรมเมอร์ส่วนใหญ่ก็จะรู้กันอยู่แล้ว แต่ แต่ แต่ … บทความนี้จะเป็นการอธิบายถึงความเข้าใจลึกๆที่ควรจะเป็นของ API และทำไมถึงเป็นเช่นนั่น
จากประสบการณ์ส่วนตัวของผม ที่ต้องทำงานกับหลายทีม กับฟรีแลนซ์บ้างในบางครั้ง
เริ่มโปรเจค : มักจะเจอคำว่า มันมีข้อมูลอยู่แล้ว API ง่ายๆ ( คำนี้เจ็บปวดสำหรับคนทำงาน … ง่ายก็ทำเองสิ 555 )
จบโปรเจ็ค : มักเจอคำว่า ช้าตอนทำ API มันยุ่งยาก
ทำไมหนะเหรอ จริงๆแล้ว API เป็นส่วนสำคัญหลักๆไม่แพ้กับ Backoffice หรือ Front-end เลย ทำไมหนะเหรอ
1. เป็นตัวกำหนดความเร็วในการเขียนหน้าบ้าน
เพราะจะมีผลกับหน้าบ้านเวลานำข้อมูลมาวางเพื่อแสดงผล ในบางครั้งที่ควรจะเขียนโปรแกรม 2-3 บรรทัด กลับต้องมาเขียนตัวแปลงค่าวาง Loop เพื่อปรับรูปแบบให้เหมือนกับที่หน้าบ้านออกแบบไว้ 30- 40 บรรทัด
2. เป็นตัวป้องกันให้ไม่เกิดหน้า Error
สามารถดักค่าต่างๆเพื่อไม่ให้หน้าบ้านแสดงผลผิดพลาดเช่น nil, null, type (int, float, …), ค่าว่าง, หรือแม้แต่ไม่สามารถติดต่อ Database ได้ ก็สามารถส่ง Header เพื่อให้หน้าบ้านเตือน User ก็สามารถทำได้
3. เป็นตัวกำหนดความเร็วในการโหลดข้อมูล
บางครั้งเจอคนทำ API ที่ Feed ข้อมูลให้ทั้งหมดในการโหลดครั้งเดียว (หรือเรียกว่า query *) แล้วข้อมูลเยอะ เซฟเวอร์ก็สามารถล่มได้ด้วย API ตัวเดียวเช่นกัน ในการออกแบบหากมีข้อมูลเยอะๆก็ควรมีการแบ่งหน้า หรือค่อยโหลดที่ละส่วน เหมือนกับพวกเวปข่าวสารทั่วไป แล้วยังไม่รวมถึงการออกแบบ “แคช” ที่เขาเรียกว่า mem-cached หรือ file-cached ที่สามารถทำให้โหลดข้อมูลเร็วในไม่ถึง 1 วินาที
4. เป็นตัวกำหนดการพัฒนาของงาน
หากออกแบบ API ไม่ดี อาจทำให้ที่เราทำไม่สามารถพัฒนาต่อได้เลยก็มีให้เห็นเยอะมาก เขียนเฉพาะงานนี้แต่เมื่อ User มีการขอปรับเปลี่ยนบางอย่าง กลายเป็นต้องเขียน API ใหม่ ในเมื่อบางครั้งหากออกแบบดีๆ อาจไม่ต้องทำอะไรที่ Front-end ปรับแค่ API ก็สามารถเพิ่ม ลด หรือปรับเปลี่ยนหน้าตาของผลงานได้ เช่น
{
"menu1":[
{
"id":"1",
"title":"home",
"icon":"a.jpg"
},{
"id":"2",
"title":"promotion",
"icon":"b.jpg"
}
],
"menu2":[
{
"id":"3",
"title":"news",
"icon":"c.jpg"
}
]
}
จากตัวอย่างข้างบน ดูเหมือนจะดีแล้ว แต่เมื่อนำไปใช้งานจริง จะค่อนข้างยาก เพราะถูกกำหนดชื่อของ menu ตายตัว ทำให้เมื่อนำไปใช้งาน ต้องสร้างฟังชั่นเพิ่มเพื่อจับ หัวขอเมนู (menu1, menu 2) และหากต้องเพิ่มเมนูที่ 3 อาจต้องแก้ Front-end เพื่อให้รองรับกับการเพิ่มเมนู
ซึ่ง API จริงที่ควรจะเป็น น่าจะเป็นแบบนี้
[
{
"header":"menu1",
"data": [
{
"id":"1"
"title":"home",
"icon":"a.jpg"
},{
"id":"2",
"title":"promotion",
"icon":"b.jpg"
}
]
},{
"header":"menu2",
"data":[
{
"id":"3",
"title":"news",
"icon":"c.jpg"
}
]
}
]
จะเห็นได้ว่า เมื่อเป็นรูปแบบนี้ เราสามารถ โหลดข้อมูลลงในตัวแปร Array ได้เลย และง่ายในการเขียน loop เพื่อแสดงผล สามารถเพิ่มเมนูจาก API โดยไม่ต้องแก้ทาง Front-end เลย
5. เป็นตัวกำหนดความต่อเนื่องของงาน
การออกแบบ API ควรกำหนดรูปแบบให้ชัดเจน และ Parameter ที่เหมือนๆกัน ไม่เช่นนั่นงานอาจจะสะดุด หรือหยุดเสียเวลาโดยเปล่าประโยชน์ ยกตัวอย่างเช่น
API : Load Profile
{
"firstname":"abc",
"lastname":"def",
"mobile":"012345678",
"email":"artdevil.t.t@gmail.com"
}
API : Update Profile
{
"Name":"abc",
"Sername":"def",
"Mobile":"012345678",
"Email":"artdevil.t.t@gmail.com"
}
ดูแล้วก็เหมือนๆกันมีชื่อ นามสนุก เบอร์โทรศัพท์ และ email เหมือนกัน แต่จริงๆแล้วเป็นปัญหาในการทำงานอย่างมาก เพราะหากดูที่ตัวแปลมีตัวใหญ่ตัวเล็กไม่เหมือนกัน เวลาจะอัพเดทต้องมาทำการเขียน code เพิ่มในการนำข้อมูลไปอัพเดทและง่ายต่อการผิดพลาด และยิ่งถ้ามีข้อมูลเยอะๆ จะยากต่อการตรวจสอบด้วย
ผมแนะนำว่า : API ที่ควรจะเป็น ควรโหลดสิ่งใดมาก็ควรอัพเดทสิ่งนั่นกลับไปได้
ผมก็ไม่ได้รู้อะไรมาก สิ่งที่เขียนขึ้นมามักมาจากตัวอย่างของ API เจ้าใหญ่ๆ เช่น Google, Facebook ที่เขาออกแบบมา และเนื่องด้วยผมก็เคยสงสัยทำไมต้องเขียนแบบนี้ แต่พอได้ทำงานจริงเจองานที่หลากหลายเยอะๆก็เข้าใจขึ้นทีละเล็กที่ละน้อย ว่าแบบไหนเหมาะสมกับงานแบบไหน
บทความนี้ผมเขียนขึ้นมาเพราะอยากให้คนที่อ่านได้เข้าใจถึงการทำ API มันไม่ได้ง่ายและก็ไม่ได้ยากหากเข้าใจ หากคุณเป็นคนเขียน API อยากให้คำนึงถึงคนที่จะนำไปใช้งานด้วย งานของเราจะได้มีประสิทธิ์ภาพ ไม่ต้องมาแก้งานทีหนึ่งก็เขียนใหม่ทีหนึ่ง ออกแบบดีๆเขียนมาครั้งเดียวใช้ได้ยาวๆ จะดีกว่า
สำหรับ API เป็นหัวใจหลักของงานเลย อย่าละเลย มันจะทำให้ทำงานได้ง่ายและรวดเร็วยิ่งขึ้น
“ที่กล่าวมา มาจากประสบการ์ณตรงของผมเอง หากผิดพลาดประการใดขออภัยนะที่นี้ด้วย”