โปรเจกต์ API Blueprint ซึ่งเคยเป็นทางเลือกที่น่าสนใจแทน OpenAPI/Swagger สำหรับการจัดทำเอกสาร API ได้ถูกประกาศตายอย่างเป็นทางการโดยชุมชนนักพัฒนา ภาษาอธิบาย API ระดับสูงที่มีจุดมุ่งหมายเพื่อทำให้การออกแบบ API เข้าถึงได้ง่ายขึ้นผ่าน syntax แบบ Markdown ไม่ได้รับการดูแลรักษาอย่างต่อเนื่องอีกต่อไป
ข้อมูลจำเพาะหลักของ API Blueprint:
- ประเภทสื่อ:
text/vnd.apiblueprint - นามสกุลไฟล์:
.apib - ใบอนุญาต: MIT
- ไวยากรณ์: ใช้พื้นฐาน Markdown
- การรองรับของ GitHub: รองรับการเน้นไวยากรณ์อย่างเต็มรูปแบบ
การซื้อกิจการของ Oracle ฆ่าการพัฒนาของชุมชน
การตายของโปรเจกต์นี้สามารถย้อนกลับไปถึงการซื้อกิจการของ Oracle ที่ซื้อบริษัทเจ้าของ API Blueprint หลังจากการซื้อกิจการ repository สาธารณะทั้งหมดถูกเก็บถาวรโดยเจ้าของ ทำให้ชุมชน open-source ไม่มีการสนับสนุนอย่างเป็นทางการหรือทิศทางการพัฒนา GitHub repository ตอนนี้มีสถานะ archived by owner ซึ่งเป็นสัญญาณของการสิ้นสุดการพัฒนาอย่างต่อเนื่อง
รูปแบบการซื้อกิจการของบริษัทนี้กลายเป็นเรื่องที่คุ้นเคยในโลกเทคโนโลยี ที่โปรเจกต์ open-source ที่มีแนวโน้มดีถูกดูดซับเข้าไปในบริษัทใหญ่ เพียงเพื่อจะถูกยกเลิกอย่างเงียบ ๆ เมื่อไม่สอดคล้องกับลำดับความสำคัญของบริษัท
ชุมชนตั้งคำถามเกี่ยวกับความพยายามฟื้นฟูโปรเจกต์
แม้จะถูกทิ้งอย่างเป็นทางการแล้ว นักพัฒนาบางคนยังคงค้นพบ API Blueprint และโพสต์เกี่ยวกับมันบนแพลตฟอร์มโซเชียล ทำให้เกิดความสับสนเกี่ยวกับสถานะปัจจุบันของโปรเจกต์ สมาชิกชุมชนรีบชี้แจงว่าโพสต์เหล่านี้แสดงถึงข้อมูลที่ล้าสมัยมากกว่าการอัปเดตโปรเจกต์จริง ๆ
สับสนว่าทำไมถึงโพสต์เรื่องนี้ตอนนี้ - โปรเจกต์ตายมาหลายปีแล้วเหมือนจะเป็น
ความขาดการเชื่อมต่อนี้เน้นให้เห็นว่าโปรเจกต์ที่ถูกทิ้งสามารถหมุนเวียนต่อไปในชุมชนนักพัฒนานานหลังจากที่ประโยชน์ในทางปฏิบัติสิ้นสุดลงแล้ว
ข้อได้เปรียบทางเทคนิคหายไปให้กับทางเลือกที่ดีกว่า
จุดแข็งหลักของ API Blueprint อยู่ที่แนวทาง Markdown-based ซึ่งทำให้ specification อ่านได้ง่ายกว่ามากใน plain text editor เมื่อเปรียบเทียบกับรูปแบบ YAML ของ OpenAPI ภาษานี้ยังสนับสนุนการจัดแต่งเอกสารที่หลากหลายและได้รับการยอมรับอย่างเป็นทางการจาก GitHub ด้วย syntax highlighting สำหรับไฟล์ .apib
อย่างไรก็ตาม โปรเจกต์เผชิญกับข้อจำกัดในการจัดการสถานการณ์ API ที่ซับซ้อน เช่น การระบุ response type หลายประเภทด้วย content header ที่แตกต่างกัน ในขณะเดียวกัน OpenAPI พัฒนาอย่างมีนัยสำคัญ เพิ่มฟีเจอร์ที่ทรงพลังเช่น polymorphism ผ่าน oneOf constructs แม้ว่านักพัฒนาบางคนจะโต้แย้งว่าสิ่งนี้ทำให้มันซับซ้อนเกินไป
Microsoft TypeSpec ได้กลายเป็นทางเลือกสมัยใหม่ ได้รับการพัฒนาอย่างต่อเนื่องและใช้สำหรับบริการ Azure ไม่เหมือน API Blueprint ที่ถูกทิ้ง TypeSpec ได้รับการสนับสนุนจากบริษัทและยังคงพัฒนาต่อไปด้วยการใช้งานองค์กรในโลกจริง
ทางเลือกสมัยใหม่แทน API Blueprint:
- OpenAPI/Swagger: มาตรฐานอุตสาหกรรม ใช้ YAML เป็นฐาน มีเครื่องมือที่หลากหลาย
- Microsoft TypeSpec: มีการพัฒนาอย่างต่อเนื่อง ใช้สำหรับบริการ Azure
- JSON Schema: สำหรับการกำหนดโครงสร้างข้อมูล
- AsyncAPI: สำหรับ API แบบ event-driven
บทเรียนสำหรับความยั่งยืนของ Open Source
เรื่องราวของ API Blueprint เป็นเครื่องเตือนใจถึงความเปราะบางของโปรเจกต์ open-source ที่พึ่งพาผู้สนับสนุนองค์กรอย่างหนัก แม้ว่าโปรเจกต์จะเป็น open-source ภายใต้ใบอนุญาต MIT แต่ความเป็นจริงในทางปฏิบัติคือการพัฒนาของชุมชนไม่สามารถรักษาโมเมนตัมได้หลังจากการสนับสนุนขององค์กรหายไป
สำหรับนักพัฒนาที่ใช้ API Blueprint อยู่ในปัจจุบัน การย้ายไปยังทางเลือกที่ได้รับการดูแลรักษาอย่างต่อเนื่องเช่น OpenAPI หรือ TypeSpec กลายเป็นสิ่งจำเป็นมากขึ้นเมื่อระบบนิเวศก้าวไปข้างหน้าโดยไม่มีการรับประกันความเข้ากันได้แบบย้อนหลัง
อ้างอิง: api blueprint