第一款 MySklad API 出現在 10 年前。一直以來，我們一直致力於 API 的現有版本並開發新版本。而API的幾個版本已經被埋沒了。
本文將包含很多內容：API 是如何創建的、為什麼雲端服務需要它、它為用戶提供了什麼、我們成功地犯了哪些錯誤以及我們下一步想要做什麼。
我的名字是奧列格·阿列克謝耶夫 ，我是MySklad的技術總監和共同創辦人。
為什麼要為服務建立 API
我們的客戶是數以萬計的企業家，他們積極使用雲端解決方案：銀行、線上商店、商品會計、CRM。一旦你連接到其中，就很難停下來。而現在第五、第八、第十個服務讓創業者的工作變得更輕鬆，但是使用者在這些雲端服務之間傳輸資料是手動的。工作變成了一場惡夢。
顯而易見的解決方案是讓用戶能夠在雲端服務之間傳輸資料。例如，將資料匯入和匯出為文件，然後可以將其上傳到所需的服務。文件通常會更改以適應每個服務的格式。這或多或少是簡單的手工工作，但隨著這些服務數量的增加，執行起來變得越來越困難。
因此，下一步就是API。有了它，雲端服務受益於它在一個點連接多個服務的事實。這種生態系統的出現會因為額外的機會而吸引新客戶。具有新功能的產品變得更有利可圖、更有用。
如果您創建自己的程式設計接口，就會吸引以程式設計師的形式出現的第三方銷售人員，他們透過 API 了解您的產品。他們開始基於提議的 API 建立解決方案，並透過自動化客戶任務來賺錢。
MySklad 會計系統是基於簡單的流程。主要是處理主要文件，接收和運輸貨物的能力，以及根據主要文件接收業務報告。還有資料傳輸，例如傳輸到雲端會計，以及從銀行系統或零售網點接收資料。我們也與線上商店合作：我們接收有關產品的資訊並發送有關餘額的資訊。
MySklad的第一個API
在 MySklad 使用 API 的 10 年裡，我們已經獲得了各種集成，使我們能夠交換資料、與銀行合作、付款和使用外部電話。
第一年，我們使得下載任何 XML 格式的資料成為可能。當時，用戶將資料離線保存（而不是保存在雲端）要清晰得多，也更常見，我們把它提供給了他們。透過從介面手動導出開始上傳。也就是說，它還不能被稱為 API。
同時，我們開始與 Rusagro 公司合作 - 他們已經在使用「成人」ERP 進行生產和銷售計劃，但他們在 MySklad 的工廠實現了貨車裝載的自動化。這就是我們獲得真正 API 的初步基礎的方式：我們的服務和 ERP 之間的交換是透過發送包含所有類型文件資料的大文件來進行的。
對於大量資料交換來說，這是一個不錯的選擇，但是除了文件之外，我們還必須傳輸它們的依賴項：有關貨物、承包商和倉庫的資訊。匯出時產生這樣的轉儲並不難，但匯入時解析起來卻相當困難，因為所有資訊都在一個套件中：包括關於新文件和現有文件的資訊。
第一個 XML API 並沒有存在多久——兩年後我們開始重建它。即使在工作開始時，我們在建立軟體介面時也犯了一些錯誤。
XML API 是如何製作的：我們的一位架構師提供的插圖。順便說一下，請繼續關注他的文章。
以下是我們的主要錯誤：
- JAXB 標記是直接在實體 bean 上完成的。我們使用 Hibernate 與資料庫通信，並為相同的 bean 製作了 JAXB 標記。這個錯誤幾乎立即出現：對資料結構的任何更新都導致需要緊急通知每個使用該 API 的人，或建立一個拐杖來確保與先前的資料結構的兼容性。
- API 作為一個附加元件而發展，我們最初並沒有定義它是產品的哪一部分。他們沒有考慮 API 是否重要，或者是否有必要為其第一批客戶端保持向後相容性。一度，API用戶數量約佔少數的5%，且沒有受到關注。一次性完成的通用過濾導致我們被用作後端。這種過濾根本不是 GraphQL，而是類似的東西 - 它通過大量查詢字串參數進行工作。有瞭如此強大的工具，用戶很難抗拒，請求被轉移給我們，以便直接從他們的線上商店的 UI 發送。這種情況是一個令人不快的意外，因為提供這樣的服務應該需要不同的定價以及對 API 本身作為產品的普遍不同的理解。
- 由於 API 並不是作為主要產品開發的，因此 API 文件是透過逆向工程在剩餘基礎上製作和發布的。這條路看似簡單方便，卻與合約制工作相矛盾。這是當某個元件具有預設的操作方案時。開發人員依照這個方案和任務來實現，組件經過測試，客戶收到符合分析師想法的產品。逆向工程將一種簡單存在的產品推向市場：帶有拐杖、奇怪的解決方案和自行車，而不是必要的功能。
- 透過 API 發出的整個請求流只能作為 Nginx 或應用程式伺服器日誌進行分析。這不允許我們識別主題領域，也許除了用戶和訂閱者之外。如果沒有辦法規範應用程式或客戶註冊，就無法分析情況。這個問題對 API 的開發影響最小；更多的是了解其相關性和功能。
嘗試二：REST API
2010年，我們嘗試建立一個線上記帳的交易系統－BukhSoft。沒有起飛。但在整合過程中，出現了一個成熟的 API：REST 交換服務，其中沒有諸如以 RPC 呼叫形式存取操作之類的自由。與 API 的所有通訊都轉為標準模式進行休息：查詢行包含實體的名稱，並且使用該實體執行的操作是使用 http 方法指定的。我們添加了基於實體更新時間的過濾，用戶現在有機會使用其係統建立複製。
同年，出現了用於卸載倉庫和庫存餘額的 API。系統中最有價值的部分已透過 API 可供使用者使用 - 交換主要文件以及餘額和商品成本的計算資料。
2015 年 XNUMX 月，RetailCRM 發布了第一個存取我們 API 的第三方函式庫。它開始被相當積極地使用，隨著整個服務的受歡迎程度不斷增長，API 上的負載增長速度快於 Web 介面上的負載增長速度。有一天，成長變成了負載激增。
這個跳轉（如左側箭頭所示）讓為我們的 API 提供服務的伺服器感到非常驚訝。我們花了一週的時間來弄清楚到底是什麼產生了這個負載。事實證明，這些請求與從客戶端前端傳輸到我們的 API 的請求相同。大約有 50 名顧客吃完了所有東西。就在那時，我們意識到我們的錯誤之一——完全缺乏限制。
因此，我們對同時請求的數量進行了限制。現在可以從一個帳戶同時開啟不超過兩個請求。這足以在複製模式下工作以進行批次模式的資料交換。從那一刻起，那些想要使用我們作為後端的人就被迫更好地遵守關稅，因為他們在他們的軟體中引入了多個帳戶的工作。
我們來整理一下
從2014年開始，現有API的需求已成為業務的重要組成部分，而API本身在與客戶端的資料交換中產生了最大量的資料。 2015 年，我們啟動了一個清理 API 的專案。我們選擇 JSON 而不是 XML 作為格式，並開始根據上一版本實作過程中確定的功能來建構它：
- 管理版本的能力。版本控制可讓您開發新版本，而不會影響現有應用程式或破壞使用者體驗。
- 用戶能夠在他收到的回應本身中查看元資料。
- 能夠交換大型文檔。如果我們處理一個超過 4-5 個位置的文檔，這就會成為伺服器的一個問題：一個長事務，一個長 http 請求。我們建立了一種特殊的機制，可讓您部分更新文件並透過將文件傳送到伺服器來管理該文件的各個位置。
- 以前的版本中也存在用於複製的工具。
- 負載限制就像以前版本中踩過的耙子的遺產。我們引入了對一段時間內的請求數、並行請求數和來自一個IP位址的請求數的限制。
從那時起，我們發布了兩個小版本的 API，並推出了幾個專門的 API，但整體方法保持不變。更新的交換格式和新的架構使得更快地修正 API 中的缺陷成為可能。
今天的 MySklad API
如今，MySklad API 解決了許多問題：
- 與網路商店、會計系統、銀行進行資料交換；
- 取得計算數據和報告；
- 用作客戶端應用程式的後端 - 我們的行動應用程式和桌面收銀機透過 API 工作
- 發送有關 MySklad 中資料變更的通知 - webhooks；
- 電話；
- 忠誠度系統。
基於 API，我們的執行長 Askar Rakhimberdiev 在四個小時內，我編寫了一個電報機器人，透過 API 提取剩菜：
現在乾數字。
以下是舊 REST API 的統計資料：
- 400家公司；
- 600 個用戶；
- 每天 2 萬個請求；
- 200 GB/天的傳出流量。
以下是我們為所有 MySklad API 提出的方案：
- 超過 70 個整合（其中一些可以在此處查看 );
- 8500家公司；
- 12 個用戶；
- 每天 46 萬個請求；
- 2 TB/天的傳出流量。
下一步是什麼
API開發計劃正在積極討論中。我們盡力考慮使用者為我們提供的操作體驗。一次完成所有事情並不總是可能的，但新版本的 API 即將推出，它具有更方便的元資料和更簡潔的結構、用於身份驗證的 OAuth 以及內建在介面中的應用程式 API。
您可以在專為 MySklad 整合開發人員提供的網站上關注新聞： .
來源： www.habr.com
