หน้านี้แปลจากภาษาอังกฤษ
เครื่องมือนักพัฒนา
สร้างเครื่องมือทดสอบและดีบัก API
Kliv คือ AI แอปบิลเดอร์ อธิบายเครื่องมือทดสอบและดีบัก API ที่ทีมของคุณต้องการ ไม่ว่าจะเป็นคำขอที่บันทึกไว้ การตรวจสอบตามกำหนดเวลา การเปรียบเทียบผลตอบกลับ อินซิเดนต์ หรือกำแพงกั้นสิทธิ์พาร์ทเนอร์ แล้ว Kliv จะสร้างให้
เพียงกรอกไอเดียของคุณลงในกล่องข้อความแล้ว AI จะสร้างมันขึ้นมาให้คุณ
Kliv คืออะไร
Kliv ไม่ใช่โปรแกรม API client บนเดสก์ท็อป และไม่ใช่บริการเก็บคอลเลกชันคำขอแบบใช้ร่วมกัน แต่เป็น AI ที่สร้างซอฟต์แวร์ให้คุณ
คุณอธิบายแอปที่ต้องการด้วยคำพูดง่ายๆ แล้ว Kliv จะสร้างฐานข้อมูล ตรรกะการทำงาน หน้าจอ งานตามกำหนดเวลา และกฎการเข้าถึงให้ทั้งหมด คุณเป็นเจ้าของผลลัพธ์และแก้ไขภายหลังได้ด้วยการขอให้เปลี่ยนแปลง มันไม่ใช่พื้นที่ทำงานแบบเทมเพลต
ในหน้านี้ แอปนั้นคือเวิร์กเบนช์สำหรับทดสอบและดีบัก API Kliv สร้างเว็บแอปได้หลากหลายรูปแบบ ส่วนแอปนี้ช่วยให้ทีมจดจำคำขอ รันการตรวจสอบ เปรียบเทียบผลตอบกลับ และผูกอินซิเดนต์เข้ากับหลักฐานเสมอ
ทำไมคอลเลกชันคำขอที่ใช้ร่วมกันจึงขยายไม่ไหว
API client บนเครื่องแต่ละคนอาจใช้ได้ดีสำหรับการเชื่อมต่อหนึ่งระบบกับวิศวกรสองคน แต่จะเริ่มมีปัญหาเมื่อมี API ของพาร์ทเนอร์หลายราย เพื่อนร่วมทีมอยู่คนละโซนเวลา และลูกค้าถามว่าระบบล่มเกิดจากโค้ดของคุณหรือการเปลี่ยนแปลงฝั่งพาร์ทเนอร์
Kliv สร้างเวิร์กเบนช์ให้เป็นระบบบันทึกกลาง (system of record) ทุก endpoint คำขอที่บันทึกไว้ ผลการตรวจสอบ ผลต่างของการตอบกลับ และอินซิเดนต์ ล้วนเป็นแถวข้อมูลในฐานข้อมูลที่ใช้ร่วมกัน พร้อมสิทธิ์การเข้าถึงและประวัติที่คงอยู่เกินกว่าเครื่องของคนใดคนหนึ่ง
โครงสร้างของคำขอหนึ่งรายการ
ห้าองค์ประกอบที่เปลี่ยนคำขอที่บันทึกไว้ให้กลายเป็นเวิร์กโฟลว์การดีบัก
ข้อมูล Endpoint
Base URL ของแต่ละสภาพแวดล้อม รูปแบบการยืนยันตัวตน ผู้ติดต่อฝั่งพาร์ทเนอร์ และบันทึกการเปลี่ยนแปลงที่คุณดูแล คำขอและอินซิเดนต์ทั้งหมดผูกอยู่กับข้อมูลนี้
คำขอที่บันทึกไว้
Header เนื้อหา (body) และเงื่อนไขตรวจสอบ เช่น สถานะที่คาดไว้ รูปแบบที่คาดไว้ และเพดานเวลาตอบสนอง คำขอจะกลายเป็นการทดสอบเมื่อมีเงื่อนไขตรวจสอบ
กำหนดการตรวจสอบ (Probe)
ฟังก์ชันฝั่งเซิร์ฟเวอร์เรียกคำขอที่บันทึกไว้ซ้ำตามกำหนดเวลา เช่น ทุกสิบห้านาทีกับ staging และทุกชั่วโมงกับ production เมื่อเงื่อนไขตรวจสอบล้มเหลว ระบบจะเปิดอินซิเดนต์ทันที
อินซิเดนต์
อินซิเดนต์หนึ่งรายการเก็บผลต่างของการตอบกลับ ไทม์ไลน์ ร้านค้าที่ได้รับผลกระทบ และใครถูกแจ้งเมื่อใด
กำแพงกั้นพาร์ทเนอร์
วิศวกรเห็นเฉพาะพาร์ทเนอร์ที่ได้รับมอบหมาย ส่วนมุมมองสถานะของลูกค้าจะแสดงเฉพาะการเชื่อมต่อของตัวเองเท่านั้น ไม่มีอะไรเกินกว่านั้น
ตัวอย่าง: ทีมผสานระบบขนส่งของนิดา
นี่คือตัวอย่างว่าทีมหนึ่งอาจใช้เวิร์กเบนช์ทดสอบ API ที่สร้างด้วย Kliv อย่างไร เป็นเพียงตัวอย่างเท่านั้น — คุณสามารถอธิบายพาร์ทเนอร์ คำขอ สภาพแวดล้อม เงื่อนไขตรวจสอบ และกฎอินซิเดนต์ของทีมคุณเองได้
พาร์ทเนอร์เปลี่ยนผลตอบกลับโดยไม่แจ้งล่วงหน้า
ผู้ให้บริการขนส่งรายหนึ่ง deploy ขึ้น staging และ version header เปลี่ยนจาก 2.13 เป็น 2.14 โดยไม่มีอีเมลแจ้งและไม่มีบันทึกการเปลี่ยนแปลงจากฝั่งผู้ให้บริการขนส่งเลย
การตรวจสอบตามกำหนดเวลาจับความเปลี่ยนแปลงของรูปแบบได้
การตรวจสอบของนิดาพบว่า payload ของการติดตามพัสดุได้ฟิลด์ใหม่มาหนึ่งฟิลด์ และฟิลด์เดิมหายไปหนึ่งฟิลด์ endpoint ยังคงตอบกลับด้วยสถานะ 200 แต่เงื่อนไขตรวจสอบรูปแบบล้มเหลว
อินซิเดนต์เปิดขึ้นพร้อมผลต่างแนบมาด้วย
ร้านค้าที่ได้รับผลกระทบถูกระบุชื่อจากข้อมูลจริง เพราะมีเพียงสองร้านที่ส่งสินค้าผ่านผู้ให้บริการขนส่งรายนี้ ระดับความรุนแรงจึงไม่ต้องอาศัยการเดา
ทีมเรียกดู staging และ production เทียบกันแบบเคียงข้าง
ในวันจันทร์ คำขอที่บันทึกไว้ถูกรันกับทั้งสองสภาพแวดล้อมในหน้าจอเดียว ขอบเขตของการเปลี่ยนแปลงชัดเจน วิธีแก้คือการอัปเดต mapping และการตรวจสอบทั้งหมดอยู่ในหน้าจอเดียว
ลูกค้าเห็นไทม์ไลน์เฉพาะส่วนของตน
ร้านค้าเห็นหน้าอินซิเดนต์ของตัวเอง ว่าอะไรเปลี่ยนไป ทีมรู้เมื่อใด และแก้ไขอย่างไร ส่วนการเชื่อมต่อของร้านค้ารายอื่นจะไม่ปรากฏให้เห็น
อธิบายเวิร์กเบนช์ API ที่คุณต้องการ
Kliv สร้างจากคำอธิบายของคุณ ดังนั้นควรระบุพาร์ทเนอร์ สภาพแวดล้อม กำหนดการ เงื่อนไขตรวจสอบ กฎอินซิเดนต์ และใครเห็นอะไรได้บ้าง ยิ่งให้รายละเอียดมาก เวอร์ชันแรกก็ยิ่งใกล้เคียงกับที่คุณต้องการ
เวิร์กเบนช์ API ผู้ให้บริการขนส่ง
คำขอที่บันทึกไว้ การตรวจสอบ และอินซิเดนต์สำหรับพาร์ทเนอร์ขนส่ง
“สร้างเวิร์กเบนช์ทดสอบ API สำหรับระบบเชื่อมต่อขนส่งของเรา บันทึกคำขอแยกตามผู้ให้บริการขนส่งแต่ละราย เก็บ Base URL ของ staging และ production รันการตรวจสอบ staging ทุก 15 นาที รันการตรวจสอบที่ปลอดภัยต่อ production ทุกชั่วโมง ตรวจสอบสถานะ 200 ฟิลด์การติดตามพัสดุที่จำเป็น และเวลาตอบสนองต้องไม่เกิน 800 มิลลิวินาที แล้วเปิดอินซิเดนต์พร้อมผลต่างของการตอบกลับแบบเต็มและรายชื่อร้านค้าที่ได้รับผลกระทบ”
เครื่องมือตรวจสอบ Sandbox การชำระเงิน
เฝ้าดูพาร์ทเนอร์ชำระเงินก่อนปล่อยใช้งานจริง
“สร้างเครื่องมือตรวจสอบ API การชำระเงินที่เรียกคำขอ authorization, capture, refund และการยืนยัน webhook ที่บันทึกไว้ซ้ำทุกชั่วโมงกับ sandbox ตรวจสอบรูปแบบผลตอบกลับ สถานะ และเวลาตอบสนองต้องไม่เกิน 500 มิลลิวินาที แล้วเปิดอินซิเดนต์พร้อมผลต่างเมื่อการตรวจสอบใดล้มเหลว”
พอร์ทัลสถานะสำหรับลูกค้า
ให้ร้านค้าแต่ละรายเห็นประวัติการเชื่อมต่อของตัวเอง
“สร้างพอร์ทัลสถานะสำหรับลูกค้าที่ร้านค้าแต่ละรายเข้าสู่ระบบเพื่อดู uptime อินซิเดนต์ และประวัติการตรวจสอบเฉพาะการเชื่อมต่อของตัวเองเท่านั้น ส่งอีเมลแจ้งเตือนเมื่ออินซิเดนต์เปิดขึ้น เปลี่ยนสถานะ หรือได้รับการแก้ไข”
เบื้องหลังคอนโซล
การตรวจสอบคือฟังก์ชันตามกำหนดเวลา การตรวจสอบแต่ละรายการคือฟังก์ชันฝั่งเซิร์ฟเวอร์ที่ทำงานตาม cron มันเรียกคำขอที่บันทึกไว้ซ้ำ ประเมินเงื่อนไขตรวจสอบ แล้วบันทึกผลลัพธ์เป็นแถวข้อมูลหนึ่งแถว
คีย์ของพาร์ทเนอร์อยู่ฝั่งเซิร์ฟเวอร์เท่านั้น คีย์ของ sandbox และ production ถูกเก็บโดยแพลตฟอร์มและฉีดเข้าไประหว่างการทำงาน คีย์เหล่านี้ไม่ปรากฏในคอลเลกชันที่ export ออกมา ไม่อยู่ในเครื่องคอมพิวเตอร์ส่วนตัว และไม่อยู่ใน wiki การตรวจสอบ staging จะรันด้วยคีย์ production ไม่ได้ ถ้าคุณแยกสภาพแวดล้อมไว้ต่างหาก
กำแพงกั้นคือกฎของข้อมูล วิศวกรที่ถูกกำหนดขอบเขตไว้สองผู้ให้บริการขนส่งจะเห็นข้อมูลกลับมาเพียงสองรายจากตารางเดียวกัน ลูกค้าเห็นเฉพาะมุมมองสถานะของตัวเอง กฎความเป็นส่วนตัวถูกบังคับใช้ก่อนที่แถวข้อมูลจะถูกส่งออกไป
เพราะนี่คือแอปจริง มันจึงขยายไปสู่ส่วนที่ลูกค้าใช้งานได้ เช่น หน้าสถานะสำหรับร้านค้า สรุปผลการตรวจสอบรายสัปดาห์ทางอีเมล และเอเจนต์ที่ตอบคำถามอย่าง “API อัตราค่าขนส่งเปลี่ยนแปลงล่าสุดเมื่อใด” จากประวัติอินซิเดนต์ของคุณเอง
Kliv ยังเขียนชุดทดสอบระหว่างที่สร้างแอป และสามารถระงับการเผยแพร่ไว้จนกว่าชุดทดสอบจะผ่าน หน้าการทดสอบ อธิบายแนวทางนี้ไว้
คำถามที่พบบ่อย
Kliv คืออะไรกันแน่
Kliv คือ AI แอปบิลเดอร์ คุณอธิบายเวิร์กโฟลว์การทดสอบ API ที่ต้องการ แล้วมันจะสร้างแอปจริงที่มีคำขอที่บันทึกไว้ กำหนดการตรวจสอบ อินซิเดนต์ ผลต่าง และมุมมองที่จำกัดสิทธิ์
ผมจะได้แอปจริง หรือแค่เทมเพลต
แอปจริง endpoint เงื่อนไขตรวจสอบ กำหนดการ สภาพแวดล้อม อินซิเดนต์ และกฎการเข้าถึงของคุณถูกเก็บไว้ในฐานข้อมูลที่สร้างขึ้นเฉพาะสำหรับเวิร์กโฟลว์ของคุณ
แก้ไขแอปได้หลังจากสร้างเสร็จไหม
ได้ คุณสามารถเพิ่มพาร์ทเนอร์ เงื่อนไขตรวจสอบ กำหนดการ ฟิลด์อินซิเดนต์ มุมมองสำหรับลูกค้า หรือสภาพแวดล้อมใหม่ ได้โดยขอให้เปลี่ยนแปลงด้วยคำพูดง่ายๆ
การตรวจสอบรันกับ production ได้โดยไม่สร้างความเสียหายไหม
ได้ คุณกำหนดว่าคำขอที่บันทึกไว้รายการใดปลอดภัยต่อ production คำขอที่มีลักษณะเขียนข้อมูล (write) สามารถตรึงไว้ที่ staging เท่านั้น และแต่ละสภาพแวดล้อมมีคีย์เป็นของตัวเอง
ลูกค้าเห็นเวิร์กเบนช์นี้ได้ไหม
เห็นได้เฉพาะมุมมองที่จำกัดสิทธิ์ เช่น การเชื่อมต่อของตัวเอง อินซิเดนต์ uptime และประวัติการตรวจสอบ ส่วนวิศวกรจะเห็นคอนโซลแบบเต็ม
เกิดอะไรขึ้นเมื่อเงื่อนไขตรวจสอบล้มเหลวตอนตีสาม
ระบบสร้างแถวอินซิเดนต์พร้อมแนบผลต่างของการตอบกลับ อีเมลหรือ Slack แจ้งเตือนวิศวกรเวรได้ และการตรวจสอบยังคงทำงานต่อเพื่อบันทึกการกู้คืน
นำเข้าคอลเลกชันคำขอเดิมที่มีอยู่แล้วได้ไหม
ได้ คำขอที่บันทึกไว้คือข้อมูล การนำเข้าจะทำให้คำขอเหล่านั้นมีกำหนดการ เงื่อนไขตรวจสอบ อินซิเดนต์ และกฎการเข้าถึง แทนที่จะเป็นแค่ไฟล์บนเครื่องคอมพิวเตอร์
เก็บข้อมูลลับได้อย่างปลอดภัยไหม
คีย์ API อยู่ฝั่งเซิร์ฟเวอร์เท่านั้นและถูกฉีดเข้าไปตอนที่การตรวจสอบทำงาน ไม่จำเป็นต้อง export ออกมาพร้อมกับนิยามของคำขอ
ใช้โดเมนของตัวเองได้ไหม
ได้ คอนโซลภายในและมุมมองสถานะสำหรับลูกค้าสามารถรันบนโดเมนของคุณเองได้
ย้ายออกจาก Kliv ในภายหลังได้ไหม
ได้ โค้ดของแอปซิงก์เข้ากับ Git repository ของคุณเอง การย้ายออกจึงเป็นแค่การ git pull ไม่ใช่การสร้างใหม่ทั้งหมด
ต้องใช้เครื่องมือจัดการอินซิเดนต์แยกต่างหากไหม
ไม่ต้อง อย่างน้อยก็สำหรับเวิร์กโฟลว์ที่อธิบายไว้ในหน้านี้ อินซิเดนต์สามารถอยู่ในแอปเดียวกันกับการตรวจสอบ ผลต่าง และไทม์ไลน์ที่ลูกค้าเห็นได้
เพิ่มเติมในหมวดหมู่นี้
สร้างโดยครีเอเตอร์
สำรวจสิ่งที่เป็นไปได้
ดูแอปจริงที่นักพัฒนาและครีเอเตอร์ทั่วโลกสร้างด้วย Kliv
Memory Café Coordination Tool
A warm platform for dementia-friendly cafés, connecting caregivers, volunteers, and coordinators.
Remit Record
Track remittances and household budgets seamlessly.
Next Page Book Club
Manage your book club easily with proposals, voting, and history tracking.
Northfern Tattoo Studio
Portfolio and booking site for Northfern Tattoo Studio.
Campo Agua Gestión
Sistema de gestión del agua comunitario para aldeas.
つくりて — 伝統工芸職人サイト
職人が作品を展示し、受注管理を行うサイトです。
Tidal Surf Reports
Crowd-sourced surf condition tracking app.
Riverside Commons HOA Management
A portal for HOA management at Riverside Commons.
よやくん — レストラン予約管理
小規模レストラン向けの予約管理サイトです。
Troop 214 Scout Management
A management tool for Scout Troop 214, focused on outings, advancement, and communication.
Te Kura Kaupapa Māori Whānau Board
A whānau coordination tool for Māori-medium schools.
Tsev Nyeem Ntawv Library
Mobile library coordinator for Hmong and Lao communities.
Memory Café Coordination Tool
A warm platform for dementia-friendly cafés, connecting caregivers, volunteers, and coordinators.
Remit Record
Track remittances and household budgets seamlessly.
Next Page Book Club
Manage your book club easily with proposals, voting, and history tracking.
Northfern Tattoo Studio
Portfolio and booking site for Northfern Tattoo Studio.
Campo Agua Gestión
Sistema de gestión del agua comunitario para aldeas.
つくりて — 伝統工芸職人サイト
職人が作品を展示し、受注管理を行うサイトです。
Tidal Surf Reports
Crowd-sourced surf condition tracking app.
Riverside Commons HOA Management
A portal for HOA management at Riverside Commons.
よやくん — レストラン予約管理
小規模レストラン向けの予約管理サイトです。
Troop 214 Scout Management
A management tool for Scout Troop 214, focused on outings, advancement, and communication.
Te Kura Kaupapa Māori Whānau Board
A whānau coordination tool for Māori-medium schools.
Tsev Nyeem Ntawv Library
Mobile library coordinator for Hmong and Lao communities.
จับความเปลี่ยนแปลงของเวอร์ชันก่อนที่ลูกค้าจะเจอ
อธิบายว่าทีมของคุณทดสอบ API อย่างไร ไม่ว่าจะเป็นพาร์ทเนอร์ คำขอ การตรวจสอบ เงื่อนไข และกำแพงกั้นสิทธิ์ Kliv จะสร้างเวิร์กเบนช์ที่จดจำทั้งหมดนี้ให้คุณ
