Thanawat Wongchai

Posted on Aug 6 Originally published at apidog.com

สุดยอดทางเลือก Apiary

Apiary กำลังจะปิดตัวลง Oracle ได้โพสต์ ประกาศยุติการสนับสนุน Apiary และรายงานในวงการเครื่องมือ API ระบุว่าบริการโฮสต์อาจปิดตัวราวเดือนกันยายน 2026 แม้เว็บไซต์ยังเข้าถึงได้ในวันนี้ แต่สัญญาณมีมาหลายปีแล้ว: Oracle ซื้อ Apiary ในเดือนมกราคม 2017 ยกเลิกแผนชำระเงินในปี 2018 และเครื่องมือโอเพนซอร์สที่เกี่ยวข้องอย่าง Dredd กับ Gavel ถูกเก็บถาวรแล้ว หากเอกสาร API ของคุณอยู่บน apiary.io นี่ไม่ใช่ช่วงเวลาสำหรับประเมินตัวเลือกอย่างเดียว แต่เป็นเวลาส่งออกและย้ายข้อมูลก่อนหมดโอกาส

ลองใช้ Apidog วันนี้

คำตอบโดยตรงคือ Apidog เป็นตัวเลือกทดแทน Apiary ที่ครอบคลุมการออกแบบสเปกแบบ design-first, เอกสารเชิงโต้ตอบแบบโฮสต์ และ mock server พร้อมเพิ่มความสามารถที่ Apiary ไม่ได้พัฒนาต่อ เช่น การทดสอบ API อัตโนมัติ การตรวจสอบตามสเปกเพื่อทดแทน Dredd และการรันใน CI

Apidog ใช้งานฟรีสำหรับผู้ใช้สูงสุด 4 คน และแผนชำระเงินเริ่มต้นที่ $9 ต่อผู้ใช้ต่อเดือน ข้อจำกัดสำคัญคือยังนำเข้า API Blueprint โดยตรงไม่ได้ ดังนั้นโปรเจกต์ Blueprint ต้องแปลงเป็น OpenAPI หนึ่งครั้งก่อนนำเข้า บทความนี้สรุปสิ่งที่เกิดขึ้นกับ Apiary และให้ขั้นตอนย้ายข้อมูลที่ลงมือทำได้ทันที

เกิดอะไรขึ้นกับ Apiary

Apiary ก่อตั้งในปี 2011 และทำให้แนวทาง API แบบ design-first ใช้งานได้จริงในรูปแบบผลิตภัณฑ์ โดยมี API Blueprint ซึ่งเป็นรูปแบบอธิบาย API แบบ Markdown ก่อน OpenAPI จะกลายเป็นมาตรฐานที่แพร่หลาย นอกจากนี้ยังมีเอกสารแบบสามคอลัมน์, mock server แบบโฮสต์, GitHub sync และเครื่องมือทดสอบสัญญาแบบโอเพนซอร์สอย่าง Dredd และ Gavel

หลัง Oracle เข้าซื้อกิจการในเดือนมกราคม 2017 ผลิตภัณฑ์เข้าสู่ช่วงที่มีการพัฒนาน้อยลง แผนชำระเงินถูกยกเลิกในปี 2018 ฟีเจอร์ใหม่หยุดพัฒนา และ Dredd กับ Gavel ถูกเก็บถาวร ปัจจุบัน Oracle ประกาศยุติการสนับสนุนแล้ว โดยคาดว่าบริการโฮสต์จะสิ้นสุดราวเดือนกันยายน 2026

Bump.sh ซึ่งเผยแพร่ คู่มือย้ายข้อมูลจาก Apiary แนะนำชัดเจนว่าให้ส่งออกคำอธิบาย API ก่อนระบบปิด เพราะหลังจากนั้นจะไม่มีข้อมูลให้ส่งออกอีก

ผลกระทบเชิงปฏิบัติมี 2 ข้อ:

ส่งออกสิ่งที่อยู่ใน Apiary ทั้งหมดทันที — รวมถึง API description, เนื้อหาเอกสาร, ตัวอย่าง และการตั้งค่าที่จำเป็น
ย้ายจาก API Blueprint ไป OpenAPI — เพราะเครื่องมือใน ecosystem ของ Blueprint ไม่มีการบำรุงรักษาอย่างต่อเนื่อง และ OpenAPI เป็นรูปแบบปลายทางที่รองรับอย่างกว้างขวางกว่า

สิ่งที่ต้องทดแทนจาก Apiary

ก่อนเลือกแพลตฟอร์มใหม่ ให้แยกความสามารถที่ทีมใช้อยู่ใน Apiary ออกมาให้ชัดเจน:

Design-first specification editor — เขียน API Blueprint หรือ OpenAPI ในเบราว์เซอร์ และดูเอกสารอัปเดตทันที
Hosted interactive documentation — เอกสารอ้างอิงพร้อมตัวอย่าง request/response บน URL ของ apiary.io
Mock server — endpoint จำลองที่ตอบกลับจากตัวอย่างในสเปก เพื่อให้ผู้ใช้ API เริ่ม integration ได้ก่อน backend พร้อม
GitHub sync — เก็บไฟล์สเปกไว้ใน repository และซิงค์การเปลี่ยนแปลง
Contract testing ผ่าน Dredd — รันคำขอตามสเปกกับ API จริงและรายงาน response ที่ไม่สอดคล้องกับสัญญา API

สำหรับการแทนที่ Dredd ดูเพิ่มเติมได้ที่ วิธีการตรวจสอบ API ของคุณเทียบกับสเปกโดยไม่ใช้ Dredd

แพลตฟอร์มปลายทางที่เหมาะสมจึงไม่ควรเป็นเพียงเครื่องมือแสดงเอกสาร แต่ควรครอบคลุมการออกแบบ เอกสาร การจำลอง และการตรวจสอบ API จากสเปกเดียวกัน

คำตอบ: Apidog

Apidog เป็นแพลตฟอร์มพัฒนา API ที่ครอบคลุมการออกแบบ เอกสาร การจำลอง การดีบัก และการทดสอบอัตโนมัติ โดยใช้สเปกเป็นแหล่งข้อมูลหลักเพียงชุดเดียว

สำหรับทีมที่ย้ายออกจาก Apiary ความสามารถที่เกี่ยวข้องโดยตรงมีดังนี้

เริ่มต้นด้วย design-first ได้ทันที

Apidog มีทั้ง visual editor และ code editor สำหรับ OpenAPI 3.x กำหนด endpoint, schema และ example ในที่เดียว แล้วใช้ข้อมูลนั้นสร้างเอกสาร mock และ test ต่อได้
เผยแพร่เอกสารแบบโต้ตอบได้

เอกสารมีคอนโซลสำหรับลองเรียก API รองรับโดเมนกำหนดเองและการกำหนดเวอร์ชัน ลดการผูก URL เอกสารไว้กับโดเมนของผู้ให้บริการรายเดียว
สร้าง mock response จาก schema

Apiary อาศัยตัวอย่างที่เขียนไว้เป็นหลัก ขณะที่ intelligent mock ของ Apidog สามารถสร้าง response จาก schema ได้ และเพิ่มกฎ mock แบบกำหนดเองได้เมื่อจำเป็น
แทนที่ Dredd ด้วย automated test scenarios

สร้าง scenario เพื่อส่งคำขอไปยัง API จริง ตรวจสอบ response กับ schema และเพิ่ม assertion ได้ รวมถึงรันใน CI ผ่าน Apidog CLI

เอกสารยังเผยแพร่ร่วมกับ MCP server ได้ เพื่อให้ AI agent อ่านสเปก API โดยตรง ดูรายละเอียดที่ Apidog MCP Server คืออะไร

การย้ายข้อมูลจาก Apiary ทีละขั้นตอน

Apidog นำเข้า OpenAPI, Swagger 2.0, Postman Collection, HAR, RAML, JMeter, apiDoc, I/O Docs, WADL และ Google Discovery ได้ตาม เอกสารการนำเข้าของ Apidog

อย่างไรก็ตาม API Blueprint ไม่อยู่ในรายการรูปแบบที่นำเข้าโดยตรงได้ ดังนั้น workflow ที่แนะนำคือ:

Apiary export
  -> API Blueprint
  -> แปลงเป็น OpenAPI
  -> ตรวจสอบสเปก
  -> Import เข้า Apidog
  -> สร้าง mock, docs และ test scenarios

1. ส่งออกทุกอย่างจาก Apiary ก่อน

สำหรับแต่ละโปรเจกต์:

เปิดโปรเจกต์ใน Apiary
ดาวน์โหลด API description จาก editor
หากใช้ GitHub sync ให้ตรวจสอบว่า repository มีไฟล์เวอร์ชันล่าสุด
สำรองไฟล์ export ไว้ใน version control หรือที่เก็บข้อมูลของทีม

โปรเจกต์ที่เป็น OpenAPI 3.0 อยู่แล้วสามารถข้ามขั้นตอนแปลงไฟล์ได้

ตัวอย่างโครงสร้าง repository ที่แนะนำ:

api-specs/
├── orders/
│   ├── apiary-export.apib
│   ├── openapi.yaml
│   └── migration-notes.md
├── users/
│   ├── apiary-export.apib
│   └── openapi.yaml
└── README.md

อย่ารอทำขั้นตอนนี้หลังประเมินเครื่องมือเสร็จ เพราะการส่งออกเป็นงานที่มีเส้นตายชัดเจน

2. แปลง API Blueprint เป็น OpenAPI

เครื่องมือที่ใช้ได้สำหรับการแปลง ได้แก่:

api-spec-converter จาก LucyBot
apib2swagger
openapi-format สำหรับจัดรูปแบบผลลัพธ์และอัปเกรดสเปกภายหลัง

ตัวอย่าง workflow ด้วย api-spec-converter:

npm install -g api-spec-converter

api-spec-converter \
  --from api_blueprint \
  --to openapi_3 \
  apiary-export.apib \
  > openapi.yaml

หลังแปลงแล้ว ให้ตรวจสอบสเปกด้วย linter เช่น vacuum:

vacuum lint openapi.yaml

ควรตรวจสอบด้วยตนเองเป็นพิเศษใน 2 จุดนี้:

Authentication schemes — API Blueprint ไม่ได้มีโมเดลมาตรฐานสำหรับ authentication ที่ครบถ้วน ตัวแปลงจึงอาจสร้าง securitySchemes ไม่ตรงกับระบบจริง
เนื้อหา Markdown ที่ไม่ได้ผูกกับ endpoint — ข้อความอธิบายบางส่วนอาจต้องย้ายไปอยู่ใน description, summary, tags หรือเอกสารประกอบใน OpenAPI

ตัวอย่างส่วน authentication ที่ควรมีใน OpenAPI:

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

security:
  - bearerAuth: []

3. นำเข้า OpenAPI เข้า Apidog

ใน Apidog ให้ทำตามขั้นตอนนี้:

สร้างหรือเปิดโปรเจกต์ปลายทาง
ไปที่ Project Settings
เลือก Manual Import
เลือกไฟล์ OpenAPI หรือระบุ URL ของสเปก
ตรวจสอบ endpoint, schema, example และ tags หลังนำเข้า
บันทึกสเปกเป็น baseline ของโปรเจกต์ใหม่

หลัง import แล้ว เอกสารอ้างอิงและ mock endpoint จะพร้อมใช้งานตามข้อมูลในสเปก

4. สร้างความสามารถที่ Apiary ไม่มีหรือทำได้จำกัด

หลัง import อย่าหยุดที่การย้ายเอกสาร ให้ย้าย workflow ของทีมด้วย

ตั้งค่าโดเมนเอกสาร

เผยแพร่เอกสารผ่านโดเมนที่ทีมควบคุม เช่น:

docs-api.example.com

จากนั้น redirect URL เอกสารเก่า หากทีมมีช่องทางควบคุม URL เดิมหรือหน้า developer portal ของตนเอง

สร้าง test scenario แทน Dredd

สำหรับทุก endpoint สำคัญ ให้สร้าง scenario ที่มี:

Request จริง
Environment variables สำหรับ base URL และ token
Assertion ของ status code
Assertion ของ response schema
Assertion ของ field สำคัญใน response

ตัวอย่างเงื่อนไขที่ควรตรวจสอบสำหรับ GET /orders/{id}:

- status code ต้องเป็น 200
- response ต้องตรงกับ Order schema
- id ต้องมีค่า
- total ต้องเป็น number และมากกว่าหรือเท่ากับ 0
- currency ต้องอยู่ในค่าที่ระบบรองรับ

รัน test ใน CI

ใช้ Apidog CLI เพื่อรัน scenario ใน pipeline ของคุณ ตัวอย่าง workflow โดยแนวคิด:

name: API Contract Tests

on:
  pull_request:
  push:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run API tests
        run: |
          apidog run --environment staging

คำสั่งจริงและ credential ที่ต้องใช้ควรอ้างอิงจากการตั้งค่า Apidog CLI ของโปรเจกต์

แจ้งผู้ใช้ mock URL ใหม่

หากผู้ใช้ API ภายนอกพึ่งพา mock URL จาก Apiary ให้ส่งประกาศพร้อมข้อมูลต่อไปนี้:

- วันเปลี่ยนผ่าน
- mock base URL ใหม่
- ลิงก์เอกสารใหม่
- วิธีตั้งค่า authentication
- ช่องทางรายงานปัญหา

Apiary เทียบกับ Apidog โดยสรุป

ความสามารถ	Apiary (ปัจจุบัน)	Apidog
อนาคตของแพลตฟอร์ม	ยุติการสนับสนุน; คาดว่าบริการสิ้นสุดราวกันยายน 2026	มีการพัฒนาอย่างต่อเนื่อง
รูปแบบสเปก	API Blueprint, ต่อมาคือ OpenAPI 3.0	OpenAPI 3.x, นำเข้า Swagger 2.0 ได้
โปรแกรมแก้ไขสเปก	มี	Visual editor และ code editor
เอกสารโฮสต์	มี บน apiary.io	มี รองรับโดเมนกำหนดเอง การกำหนดเวอร์ชัน และคอนโซลทดลอง
Mock server	ตอบจากตัวอย่างที่เขียนไว้	Intelligent mock จาก schema และกฎกำหนดเอง
Contract testing	Dredd ซึ่งถูกเก็บถาวร	Test scenarios, schema validation และ CI ผ่าน CLI
Automated test suite	ไม่มี	มี scenario แบบภาพและ data-driven
GitHub workflow	GitHub sync	นำเข้า/ซิงค์สเปกจาก URL หรือไฟล์ และจัดการเวอร์ชันแบบ branch-based
ราคา	ฟรี; ยกเลิกแผนชำระเงินในปี 2018	ฟรีสูงสุด 4 คน จากนั้น $9 ต่อผู้ใช้/เดือน
การส่งออก	API Blueprint / OpenAPI	OpenAPI, Markdown, HTML

ค่าใช้จ่ายในการเปลี่ยนจากเครื่องมือฟรี

Apiary อาจยังดูคุ้มค่าเพราะไม่มีค่าใช้จ่าย แต่ต้นทุนจริงของการใช้ต่อคือความเสี่ยงที่เอกสารและ mock endpoint จะหายไปเมื่อบริการปิด

จากราคาที่ประกาศไว้:

Apidog: ฟรีสำหรับ 4 คน, จากนั้น $9 ต่อผู้ใช้ต่อเดือน
SwaggerHub Team: $34.44 ต่อผู้ใช้ต่อเดือน
ReadMe Pro: $250 ต่อเดือนเมื่อชำระรายปี

ขนาดทีม	Apidog ต่อปี	SwaggerHub Team ต่อปี	ReadMe Pro ต่อปี
3 คน	$0 (แผนฟรี)	$1,240	$3,000
5 คน	$540	$2,066	$3,000
10 คน	$1,080	$4,133	$3,000
25 คน	$2,700	$10,332	$3,000

หากต้องการเพียงหน้าแสดงผลสเปกฟรีหนึ่งรายการ เครื่องมือเอกสารโดยเฉพาะอาจเพียงพอ แต่หากทีมต้องการ mock server, การทดสอบ และการทำงานร่วมกัน แผนฟรีของ Apidog สำหรับ 4 คนอาจครอบคลุม workflow เดิมของ Apiary ได้ครบกว่า

หาก Apidog ไม่ใช่ตัวเลือกที่เหมาะสม

ต้องการเฉพาะเอกสาร API

หากสเปกถูกสร้างและทดสอบจากที่อื่นอยู่แล้ว และต้องการเพียงเอกสารโฮสต์พร้อม changelog Bump.sh เป็นตัวเลือกที่ควรพิจารณา โดยเฉพาะเพราะมีคู่มือย้ายจาก Apiary โดยตรง อย่างไรก็ตาม คุณยังต้องแปลง API Blueprint เป็น OpenAPI ก่อน

ใช้ชุดเครื่องมือ SmartBear อยู่แล้ว

SwaggerHub เป็นตัวเลือกที่ใกล้เคียงกับแนวคิด hosted API specification ของ Apiary แต่ควรพิจารณาค่าใช้จ่ายต่อผู้ใช้และข้อจำกัดของการรันทดสอบ ดูการเปรียบเทียบเพิ่มเติมได้ที่ ทางเลือก SwaggerHub ที่ดีที่สุด

โฟกัสที่ governance สำหรับทีมแพลตฟอร์มขนาดใหญ่

Stoplight เหมาะกับกรณีที่องค์กรต้องการ style guide และ design governance เชิงลึก ดู ทางเลือก Stoplight ที่ดีที่สุด ก่อนตัดสินใจ

ยังต้องการใช้ API Blueprint

ไม่ควรวางแผนระยะยาวบน API Blueprint อีกต่อไป เครื่องมือของรูปแบบนี้ไม่ได้รับการบำรุงรักษา บริษัทผู้สร้างแพลตฟอร์มกำลังยุติบริการ และ OpenAPI กลายเป็นมาตรฐานที่ใช้งานแพร่หลายกว่า แปลงครั้งเดียว เก็บ OpenAPI ไว้ใน Git และใช้เป็น source of truth ต่อไป

หากต้องการอ้างอิงรูปแบบเดิม ดู คู่มือ API Blueprint ได้

คำถามที่พบบ่อย

Apiary จะปิดตัวลงเมื่อใด

Oracle ประกาศยุติการสนับสนุน Apiary แล้ว และรายงานจากผู้ให้บริการเครื่องมือ API ระบุว่าบริการโฮสต์อาจปิดตัวราวเดือนกันยายน 2026 แนวทางที่ปลอดภัยคือส่งออกข้อมูลทันที ไม่ควรรอจนถึงกำหนดปิดบริการ

Apidog นำเข้า API Blueprint โดยตรงได้หรือไม่

ไม่ได้ Apidog รองรับ OpenAPI/Swagger, Postman, HAR, RAML, JMeter, apiDoc, I/O Docs, WADL และ Google Discovery ให้แปลง API Blueprint เป็น OpenAPI ด้วย api-spec-converter หรือ apib2swagger ก่อน แล้วค่อย import ผลลัพธ์

หลังแปลง ให้ตรวจสอบ authentication scheme และเนื้อหา Markdown ที่อาจไม่ถูกแปลงเป็นคำอธิบาย endpoint โดยอัตโนมัติ

อะไรมาแทนที่ Apiary mock server

Intelligent mock server ของ Apidog สามารถสร้าง response จาก schema ในสเปกได้ และเพิ่มกฎ mock แบบกำหนดเองได้สำหรับกรณีที่ต้องการ response เฉพาะ

อะไรมาแทนที่ Dredd สำหรับ contract testing

Automated test scenarios ของ Apidog สามารถส่ง request จริงไปยัง API ตรวจสอบ response กับ schema เพิ่ม assertion และรันใน CI ผ่าน Apidog CLI ได้ ซึ่งครอบคลุมงานหลักที่ Dredd เคยทำ

Apidog ฟรีสำหรับทีมเล็กจริงหรือไม่

ใช่ แผนฟรีรองรับผู้ใช้สูงสุด 4 คน พร้อมการแก้ไขสเปก เอกสารเชิงโต้ตอบ mock server และการทดสอบ API หากเกิน 4 คน ราคาเริ่มต้นที่ $9 ต่อผู้ใช้ต่อเดือน

ส่งออกวันนี้ ไม่ต้องออกแบบใหม่

ลำดับการทำงานที่ควรทำคือ:

ส่งออกข้อมูลจาก Apiary
แปลง API Blueprint เป็น OpenAPI
ตรวจสอบ schema, authentication และตัวอย่าง
นำเข้าสเปกไปยังแพลตฟอร์มใหม่
ตั้งค่าเอกสาร mock และ contract test
แจ้งผู้ใช้ API ถึง URL ใหม่

สองขั้นตอนแรกมีเส้นตายเพราะขึ้นกับการเข้าถึง Apiary ส่วนการเลือกแพลตฟอร์มและการปรับ workflow สามารถทำต่อได้หลังจากข้อมูลถูกสำรองอย่างปลอดภัยแล้ว

เมื่อพร้อม ให้ ดาวน์โหลด Apidog หรือเริ่มใช้งานผ่านเบราว์เซอร์ แล้วนำเข้าไฟล์ OpenAPI ของคุณเพื่อสร้างเอกสาร mock และ test suite จากสเปกเดียวกัน

DEV Community