ในโลกของบริการเว็บที่แปลกประหลาด API ใหม่ที่เรียกว่า No-as-a-Service (NAAS) ได้ดึงดูดความสนใจของนักพัฒนาและผู้คลั่งไคล้เทคโนโลยี บริการเบาๆ นี้ซึ่งให้การตอบสนองการปฏิเสธแบบสุ่มผ่านจุดเชื่อมต่อ API อย่างง่าย ได้จุดประกายทั้งความสนุกสนานและการวิจารณ์ทางเทคนิคในชุมชนนักพัฒนา
ปัญหาการจำกัดอัตราการใช้งาน
บริการนี้เริ่มต้นด้วยการใช้การจำกัดอัตราการใช้งานที่เข้มงวดที่ 10 คำขอต่อนาทีต่อที่อยู่ IP ซึ่งกลายเป็นจุดปวดหัวสำหรับผู้ใช้อย่างรวดเร็ว ผู้แสดงความคิดเห็นหลายคนรายงานว่าได้รับข้อความแสดงข้อผิดพลาด Too many requests, please try again later แม้ว่าจะไม่ได้ทำคำขอใกล้เคียง 10 ครั้งเลย ซึ่งบ่งชี้ถึงปัญหาการนำไปใช้ขั้นพื้นฐานกับวิธีการที่การจำกัดอัตราการใช้งานถูกนำไปใช้
ผู้ใช้คนหนึ่งระบุว่าการจำกัดอัตราการใช้งานน่าจะถูกนำไปใช้กับที่อยู่ IP ของ Cloudflare แทนที่จะเป็น IP ของผู้ใช้แต่ละราย ทำให้ผู้ใช้ทั้งหมดที่อยู่เบื้องหลังโหนด Cloudflare เดียวกันต้องใช้โควต้าการจำกัดอัตราการใช้งานเดียวกัน ข้อสังเกตนี้ได้รับการสนับสนุนจากการมีส่วนหัวของ Express ในการตอบสนอง ซึ่งบ่งชี้ว่าการจำกัดอัตราการใช้งานเกิดขึ้นที่ระดับแอปพลิเคชันมากกว่าที่ระดับ CDN
ในการตอบสนองต่อข้อเสนอแนะที่แพร่หลายนี้ นักพัฒนา (hotheadhacker) ได้ลบการจำกัดอัตราการใช้งานออกไปในที่สุด โดยประกาศอย่างง่ายๆ ว่า: The API rate limiting has been removed
รายละเอียด API No-as-a-Service:
- URL หลัก: https://naas.isalman.dev/no
- วิธีการ: GET
- การจำกัดอัตราการใช้งานเริ่มต้น: 10 คำขอต่อนาทีต่อ IP (ปัจจุบันถูกลบออกแล้ว)
- รูปแบบการตอบกลับ: JSON พร้อมฟิลด์ "reason"
- GitHub Repository: https://github.com/hotheadhacker/no-as-a-service
ปัญหาในการใช้งาน:
- มีเพียง 25-26 คำตอบที่ไม่ซ้ำกันแม้จะอ้างว่ามี "1000+"
- คำตอบบางอย่างถูกทำซ้ำถึง 50 ครั้งในไฟล์ reasons.json
- การจำกัดอัตราการใช้งานเริ่มต้นถูกใช้ในระดับพร็อกซีแทนที่จะเป็น IP ต้นทาง
ปัญหาการตอบสนองที่ซ้ำซ้อน
อีกประเด็นสำคัญในการอภิปรายคือคุณภาพและความเป็นเอกลักษณ์ของข้อความปฏิเสธ แม้ว่าเอกสารจะอ้างว่ามีเหตุผลในการปฏิเสธสากลมากกว่า 1000 เหตุผล ผู้ใช้ที่ตรวจสอบซอร์สโค้ดพบว่าไฟล์ reasons.json มีการทำซ้ำของการตอบสนองเดียวกัน 25 รายการเป็นส่วนใหญ่
I made a lot of things like this as a noob and threw them up on github. As you gain experience, these projects become a testament to how far you've come.
บางคนคาดเดาว่าการทำซ้ำอาจเป็นวิธีการที่ตั้งใจเพื่อสร้างระบบการกระจายแบบถ่วงน้ำหนัก ซึ่งการตอบสนองบางอย่างปรากฏบ่อยกว่าอื่นๆ คนอื่นๆ แนะนำว่ามันอาจเป็นเพียงผลพวงของการใช้ LLM เพื่อสร้างรายการ เนื่องจากโมเดลภาษาขนาดใหญ่มักจะทำซ้ำรายการเมื่อถูกขอให้สร้างรายการที่ยาว
ข้อพิจารณาในการนำไปใช้
ความเรียบง่ายของโปรเจกต์นี้จุดประกายการอภิปรายที่น่าสนใจเกี่ยวกับการจัดระเบียบโค้ดและการทำงานร่วมกัน นักพัฒนาบางคนแนะนำว่าการเก็บการตอบสนองในไฟล์ JSON ขนาดใหญ่เพียงไฟล์เดียวอาจสร้างความขัดแย้งในการรวมเมื่อยอมรับการมีส่วนร่วม โดยเสนอวิธีการทางเลือกเช่นการใช้โฟลเดอร์ของไฟล์ข้อความธรรมดาที่จัดกลุ่มตามธีมหรือผู้มีส่วนร่วม
คนอื่นๆ โต้แย้งว่าสำหรับบริการเบาๆ เช่นนี้ การนำไปใช้ในปัจจุบันเพียงพอแล้ว โดยสังเกตว่าความขัดแย้งในการรวม Git ในไฟล์บรรทัดต่อบรรทัดอย่างง่ายจะค่อนข้างง่ายในการแก้ไข
ชุมชนยังเสนอการปรับปรุงที่อาจเกิดขึ้น รวมถึงการจัดการข้อผิดพลาดที่ซับซ้อนมากขึ้นซึ่งจะรักษาโทนที่ขบขันของบริการแม้เมื่อถูกจำกัดอัตราการใช้งาน ผู้ใช้คนหนึ่งแนะนำให้ขยายบริการเพื่อรวมโหมดความล้มเหลวต่างๆ ที่อาจเป็นประโยชน์สำหรับการทดสอบไคลเอนต์ HTTP เช่น รหัสสถานะ HTTP ที่แตกต่างกัน ปัญหา TLS และการตอบสนองไวยากรณ์ที่ไม่ถูกต้อง
แม้จะมีข้อจำกัดทางเทคนิค ผู้ใช้หลายคนชื่นชมอารมณ์ขันและความเรียบง่ายของโปรเจกต์ บริการนี้แสดงให้เห็นว่าแม้แต่การนำไปใช้ขั้นพื้นฐานที่สุดก็สามารถให้คุณค่าความบันเทิงและจุดประกายการอภิปรายทางเทคนิคที่น่าสนใจในชุมชนนักพัฒนา ไม่ว่าจะมองว่าเป็นความแปลกใหม่หรือโอกาสในการเรียนรู้ No-as-a-Service นำเสนอวิธีการที่สนุกสนานในการออกแบบ API ที่สอดคล้องกับนักพัฒนาในทุกระดับประสบการณ์
อ้างอิง: no-as-a-service