Kliv

    本頁面由英文翻譯而成。

    開發者工具

    打造 API 測試與除錯工具

    Kliv 是一款 AI 應用程式建構工具。描述你的團隊需要的 API 測試與除錯工具——已儲存的請求、排程探測、回應比對、事件記錄與合作夥伴權限牆——Kliv 就會把它打造出來。

    kliv.dev

    只需在文字方塊中輸入你的想法,AI 就會為你建置它

    138 字元

    什麼是 Kliv?

    Kliv 不是桌面版的 API 用戶端,也不是共用集合服務——它是一個會替你打造軟體的 AI。

    你用平常說話的方式描述需要的應用程式,Kliv 就會建好資料庫、邏輯、畫面、排程工作與存取規則。成果歸你所有,之後只要提出修改需求就能調整。這不是套版工作區。

    在這個頁面中,那個應用程式是一套 API 測試與除錯工作台。Kliv 能打造各式各樣的網頁應用程式,而這一套能幫團隊記住請求、執行探測、比對回應,並讓事件與證據緊密連結。

    為什麼共用請求集合終將撐不住

    每台筆電各裝一套 API 用戶端,在只有一個串接、兩位工程師時還撐得住。但當合作夥伴 API 一多、團隊成員分散在不同時區,又有客戶追問這次中斷究竟是你們的程式碼還是對方改了介面造成的,這套做法就行不通了。

    Kliv 把這套工作台打造成正式的紀錄系統。每個端點、每個已儲存的請求、每次探測結果、每份回應比對與每起事件,都是共用資料庫裡的一筆紀錄,權限與歷史紀錄不會只留在某個人的筆電裡。

    組成一個請求的五塊拼圖

    五種紀錄,能把一個已儲存的請求變成完整的除錯流程。

    端點紀錄

    每個環境的基礎網址、驗證方式、合作夥伴聯絡窗口,以及你自己維護的異動紀錄。請求與事件都掛在這筆紀錄底下。

    已儲存的請求

    標頭、內文,以及像是預期狀態碼、預期結構、延遲上限這類驗證條件。一旦請求附上驗證條件,它就變成了一項測試。

    探測排程

    伺服器端函式會依排程重播已儲存的請求,例如每 15 分鐘對測試環境執行一次、每小時對正式環境執行一次。只要有一項驗證失敗,就會開立事件。

    事件

    一起事件會保留回應差異比對、時間軸、受影響的商家,以及誰在什麼時候被通知。

    合作夥伴權限牆

    工程師只會看到被指派給自己的合作夥伴。客戶的狀態頁面則只顯示自己的串接內容,不會看到範圍以外的東西。

    範例:雅婷的貨運串接團隊

    以下是一個團隊實際使用 Kliv 打造的 API 測試工作台的例子。這只是示範——你可以描述自己的合作夥伴、請求、環境、驗證條件與事件規則。

    01

    合作夥伴毫無預警更動了回應

    某家貨運商在測試環境部署新版本,版本標頭從 2.13 變成 2.14。貨運商既沒有寄信通知,也沒有留下任何異動紀錄。

    02

    排程探測抓到了結構變化

    雅婷的探測發現,追蹤資料的內容多了一個欄位、少了另一個欄位。端點仍然回傳 200,但結構驗證失敗了。

    03

    事件開立時已附上差異比對

    受影響的商家直接由資料標示出來,因為只有兩家商家透過這家貨運商出貨。嚴重程度不必靠猜測。

    04

    團隊並排重播測試環境與正式環境

    星期一,同一個畫面就能對兩個環境重播同一個已儲存的請求。變動範圍一目了然,修法只是更新對應欄位,整個調查過程都留在同一個畫面上。

    05

    客戶看到的是限定範圍的時間軸

    商家看到的是自己的事件頁面:改了什麼、團隊什麼時候發現、採取了什麼行動。其他商家的串接內容則完全看不到。

    描述你想要的 API 工作台

    Kliv 會依照你的描述來打造,所以請寫清楚合作夥伴、環境、排程、驗證條件、事件規則,以及誰能看到什麼。你描述得越詳細,第一版就會越接近你要的樣子。

    kliv.dev

    貨運商 API 工作台

    為貨運合作夥伴打造已儲存的請求、探測與事件。

    “打造一個給我們貨運串接使用的 API 測試工作台。依每家貨運商儲存請求,分別記錄測試環境與正式環境的基礎網址,對測試環境每 15 分鐘執行一次探測,對正式環境安全的探測則每小時執行一次,驗證狀態碼為 200、必要的追蹤欄位齊全,以及延遲低於 800 毫秒,並在開立事件時附上完整的回應差異比對與受影響商家。”

    kliv.dev

    金流測試環境監控

    在正式上線前監控金流合作夥伴。

    “打造一個金流 API 監控工具,每小時對測試環境重播我們已儲存的授權、請款、退款與 Webhook 驗證請求。驗證回應結構、狀態碼,以及延遲低於 500 毫秒,任何驗證失敗時都要開立事件並附上差異比對。”

    kliv.dev

    客戶狀態入口網站

    讓每家商家都能查看自己的串接歷史。

    “打造一個客戶狀態入口網站,讓每家商家登入後只能查看自己串接的正常運行時間、事件與探測歷史。當事件開立、狀態變更或結案時,寄送電子郵件通知。”

    主控台之下

    探測是排程工作。 每個探測都是掛在 cron 上的伺服器端函式。它會重播已儲存的請求、評估驗證條件,並把結果寫成一筆紀錄。

    合作夥伴金鑰只留在伺服器端。 測試與正式環境的金鑰由平台保管,並在執行時才注入。它們不會出現在匯出的請求集合、筆電或內部 Wiki 裡。只要你把環境分開標示,測試探測就不可能誤用正式環境的金鑰。

    權限牆是資料規則。 一名只被指派到兩家貨運商的工程師,從同一批資料表裡也只會拿回這兩家的資料。客戶看到的是自己的狀態頁面。隱私規則會在資料回傳之前就先套用。

    因為這是一個應用程式,它能持續長出客戶可以使用的介面:商家狀態頁面、每週探測摘要,以及一個能從你自己的事件歷史中回答「費率 API 上次是什麼時候改的?」的代理。

    Kliv 在打造的同時也會寫測試,並可以在測試通過前暫緩發布。測試頁面 說明了這套規範。

    常見問題

    Kliv 到底是什麼?

    Kliv 是一款 AI 應用程式建構工具。你描述需要的 API 測試流程,它就會打造出一個真正的應用程式,內含已儲存的請求、探測排程、事件、差異比對與限定範圍的檢視畫面。

    我拿到的是真正的應用程式,還是套版?

    是真正的應用程式。你的端點、驗證條件、排程、環境、事件與存取規則,都會存放在一個為你的工作流程量身打造的資料庫裡。

    打造完成後還能修改嗎?

    可以。只要用平常說話的方式提出需求,你就能新增合作夥伴、驗證條件、排程、事件欄位、客戶檢視畫面,或新的環境。

    探測能在不造成損害的情況下對正式環境執行嗎?

    可以。你可以標示哪些已儲存的請求對正式環境是安全的。會寫入資料的請求可以固定只在測試環境執行,而每個環境都有各自獨立的金鑰。

    客戶能看到這套工作台嗎?

    他們能看到限定範圍的畫面:自己的串接、事件、正常運行時間與探測歷史。完整的主控台仍然只留給工程師。

    如果驗證在凌晨三點失敗會發生什麼事?

    系統會建立一筆事件紀錄,並附上回應差異比對。可以透過電子郵件或 Slack 通知值班工程師,探測也會持續執行,以便記錄復原情況。

    可以匯入現有的請求集合嗎?

    可以。已儲存的請求本身就是資料。匯入之後,它們就能擁有排程、驗證條件、事件與存取規則,而不再只是筆電裡的檔案。

    它能安全地儲存機密資訊嗎?

    API 金鑰只留在伺服器端,並在探測執行時才注入。不需要隨著請求定義一起匯出。

    可以使用自己的網域嗎?

    可以。內部主控台與客戶狀態頁面都能架設在你自己的網域上。

    之後可以離開 Kliv 嗎?

    可以。應用程式的程式碼會同步到你自己的 Git 儲存庫,所以離開時只需要 git pull,不必重新打造一遍。

    我需要另外準備一套事件管理工具嗎?

    不需要,至少對這裡描述的流程來說不需要。事件可以和探測、差異比對、客戶可見的時間軸放在同一個應用程式裡。

    在客戶發現之前先抓到版本變動

    描述你的團隊怎麼測試 API——合作夥伴、請求、探測、驗證條件與權限牆。Kliv 會打造出能記住這一切的工作台。