วางทฤษฎีที่เรียนมาเอาไว้ แล้วลองอ่านตรงนี้ดูว่า API ที่ดีควรมีอะไรบ้าง

แค่อยากแชร์ให้ดูว่าการเขียน API ที่ดีนั้นควรทำไงมั้ง เพราะผมก็ทำงานตรงกับ CR ส่วนใหญ่เป็นเราการสร้าง web service เพราะให้ front-end แอปมาคิวรี่เอาข้อมูลไปใช้งานต่อ

วางทฤษฎีที่เรียนมาเอาไว้ แล้วลองอ่านตรงนี้ดูว่า API ที่ดีควรมีอะไรบ้าง

1 Authentication อย่าเพียว เดียวเสียวสันหลัง บอกเลยก็เอา API ขึ้น public ควรมีการใส่รหัส พาส หรือ special charecter ที่ทำให้รู้ว่า call service จากที่ไหน เราจะได้ track ได้ ทั้งเรื่องจำนวนคนใช้ เรียกจาก app ไหน ไม่งั้นดูแลระบบยาก อีกทั้งยังเป็นการป้องกัน hacker ที่จ้องล้วงข้อมูลระดับหนึ่ง

2 Away-On กล่าวคือถึงแม้ API จะแหล่ว(จะพัง) ภายในตัว API เองเกิด error ขึ้นก็ควร return กลับมาได้ทุก request เพราะอะไรนะหรือ เพราะฝั่ง client จะได้รู้ไงว่าตวรตัดสินใจทำอะไรต่อ เช่น บอกผู้ใช้ให้ลองกดใหม่ หรือ บอกให้รีเฟรชเพื่อดูผล เป็นต้น เคยทำงานกับทีมเมกัน แม่ง return Empty string กลับมา ใครจะไปรู้ว่ะ ว่า request นั้น success หรือ fail

3 Suck Data Handler มีแต่พวกกากๆเท่านั้นแหละที่คิดว่าการเรียก API ต้องใส่ตัวแปรที่ถูกต้องเสมอ อย่าลืมว่า requirement เปลี่ยน โค๊ดเปลี่ยน การสร้าง request data ก็ต้องเปลี่ยน เช่น บอกว่า API รับค่าราคาเป็นตัวเลข เเล้วมีความต้องการลูกค้าใหม่เข้ามา ว่าให้รับได้ทุกสกุลเงิน เพราะเริ่มปั้น request ใหม่ให้จาก { "price" : "120" } เป็น { "price" : "120THB"} ตัว api เองต้องรับได้ ถ้ากรอกสกุลเงินผิด ก็ต้องไม่ error 500 ตัวเหลืองเป็นดีซ่าน เคยทำงานกับทีมเมกัน(หรือ สิงค์โปร นี้แหละลืม) มันรับค่า datetime เป็น format แปลกมาก \T20160101992\ เป็นต้น คือทำให้โอกาสพังเยอะมาก เพราะเค้าวาง business logic ของการ convert ไว้ท่ front-end

4 Friendly API ทำอะไรบอกกันด้วย เวลาเรียก Update ข้อมูล ก็ช่วยบอกด้วยว่าสำเร็จไหม ไม่ใช่หายไปเลย เเล้วให้เราคิดไปเอง จะเป็นวิธีไหนก็ได้ เช่น
- HTTP HEADER Status : 200 ok , 500 error , 404 not found
- JSON { "result" : "success" , "receipt" : "pay00001" } เป็นต้น
เอาสักอย่างที่ทำให้งาน front-end ง่ายขึ้น เคยเล่น API คนมาเลย์ เเม่งเรียกฟังชั่นเเล้วหายไปเลย ผมก็งงดิ เรียกซ้ำอีกทีก็เงียบ สุดท้ายเช็คไปเช็คมา ที่ฝั่งนั้น data duplicate เพราะโดน insert ซ้ำๆหลายรอบ เเม่งฮา database ตัวเองยังไม่เช็ค data ก่อนใส่เข้าเรคคอร์ดเลย #กุมขมับ

สี่ข้อพอ ทำได้ก็ถือว่าแข็งเเล้วแหละ

ไม่แปลกใจเลยกับเว็บรัฐบาล SQL Injection กับกรมสรรพกร

แค่เข้าไปค้นหาโรงเรียนที่อยู่ในรายชื่อบริจาคแล้วได้สิทธิลดหย่อน ดันลืมเปลี่ยนภาษาเลยกรอกชื่อโรงเรียนผิด

แล้วดันทะลึ่งไปเจอบัคอีก

ยุคนี้ SQL Injection ยังมีอยู่จริง ตามรูป

พอหอมปาก หอมคอ ไม่ไปต่อ เดี๋ยวโดน

ไม่ได้ทำอะไรเลยนะ อย่างน้อย  INFORMATION_SCHEMA.Tables ก็ lock permission ไว้

พอๆๆๆ