MySklad API ตัวแรกปรากฏขึ้นเมื่อ 10 ปีที่แล้ว ตลอดเวลานี้เราได้ทำงานกับ API เวอร์ชันที่มีอยู่และพัฒนาเวอร์ชันใหม่ และ API หลายเวอร์ชันได้ถูกฝังไปแล้ว
บทความนี้จะประกอบด้วยสิ่งต่างๆ มากมาย: วิธีสร้าง API เหตุใดบริการคลาวด์จึงต้องการสิ่งนี้ สิ่งที่มอบให้กับผู้ใช้ ข้อผิดพลาดใดบ้างที่เราจัดการเพื่อก้าวข้าม และสิ่งที่เราต้องการดำเนินการต่อไป
ฉันชื่อ Oleg Alekseev ฉันเป็นผู้อำนวยการด้านเทคนิคและผู้ร่วมก่อตั้ง MySklad
ทำไมต้องสร้าง API สำหรับบริการ
ลูกค้าของเราซึ่งเป็นผู้ประกอบการหลายหมื่นรายใช้งานโซลูชันคลาวด์อย่างจริงจัง: การธนาคาร ร้านค้าออนไลน์ การบัญชีสินค้าโภคภัณฑ์ CRM เมื่อคุณเชื่อมต่อกับสิ่งใดสิ่งหนึ่งแล้ว จะหยุดได้ยาก และตอนนี้บริการที่ห้า, แปด, สิบทำให้การทำงานของผู้ประกอบการง่ายขึ้น แต่ผู้ใช้ถ่ายโอนข้อมูลระหว่างบริการคลาวด์เหล่านี้ด้วยตนเอง งานกลายเป็นฝันร้าย
ทางออกที่ชัดเจนคือการให้ผู้ใช้สามารถถ่ายโอนข้อมูลระหว่างบริการคลาวด์ได้ ตัวอย่างเช่น นำเข้าและส่งออกข้อมูลเป็นไฟล์ ซึ่งสามารถอัปโหลดไปยังบริการที่ต้องการได้ โดยปกติไฟล์จะถูกเปลี่ยนให้เหมาะสมกับรูปแบบของแต่ละบริการ นี่เป็นการทำงานด้วยตนเองที่เรียบง่ายไม่มากก็น้อย แต่เมื่อจำนวนบริการเหล่านี้เพิ่มขึ้น การดำเนินการก็จะยากขึ้นเรื่อยๆ
ดังนั้นขั้นตอนต่อไปคือ API บริการคลาวด์จะได้รับประโยชน์จากการเชื่อมต่อบริการต่างๆ เข้าด้วยกันในจุดเดียว การเกิดขึ้นของระบบนิเวศดังกล่าวดึงดูดลูกค้าใหม่เนื่องจากโอกาสเพิ่มเติม ผลิตภัณฑ์ที่มีฟังก์ชั่นใหม่จะทำกำไรและมีประโยชน์มากขึ้น
หากคุณสร้างอินเทอร์เฟซการเขียนโปรแกรมของคุณเอง สิ่งนี้จะดึงดูดพนักงานขายบุคคลที่สามในรูปแบบของโปรแกรมเมอร์ที่รู้เกี่ยวกับผลิตภัณฑ์ของคุณด้วย API พวกเขาเริ่มสร้างโซลูชันตาม API ที่เสนอและสร้างรายได้โดยทำให้งานของลูกค้าเป็นแบบอัตโนมัติ
ระบบบัญชี MySklad ใช้กระบวนการง่ายๆ สิ่งสำคัญคือการทำงานกับเอกสารหลัก ความสามารถในการรับและจัดส่งสินค้า และรับรายงานทางธุรกิจตามเอกสารหลัก นอกจากนี้ยังมีการถ่ายโอนข้อมูล เช่น ไปยังบัญชีคลาวด์ และการรับข้อมูลจากระบบธนาคารหรือร้านค้าปลีก เรายังทำงานร่วมกับร้านค้าออนไลน์: เราได้รับข้อมูลเกี่ยวกับผลิตภัณฑ์และส่งข้อมูลเกี่ยวกับยอดคงเหลือ
API แรกของ MySklad
ตลอดระยะเวลา 10 ปีที่ MySklad ทำงานร่วมกับ API เราได้รับการผสมผสานทุกประเภทที่ช่วยให้เราสามารถแลกเปลี่ยนข้อมูล ทำงานร่วมกับธนาคาร ชำระเงิน และใช้โทรศัพท์ภายนอกได้
ในปีแรก เราทำให้สามารถดาวน์โหลดข้อมูลในรูปแบบ XML ได้ เมื่อก่อน ผู้ใช้จะเก็บข้อมูลแบบออฟไลน์ได้ชัดเจนกว่าและเป็นเรื่องปกติมากกว่ามาก และไม่ได้อยู่ในระบบคลาวด์ใดๆ และเราก็มอบข้อมูลดังกล่าวให้กับพวกเขา การอัปโหลดเริ่มต้นโดยการส่งออกด้วยตนเองจากอินเทอร์เฟซ นั่นคือยังไม่สามารถเรียกได้ว่าเป็น API
ในเวลาเดียวกัน เราเริ่มร่วมมือกับบริษัท Rusagro - พวกเขาใช้ ERP "สำหรับผู้ใหญ่" ในการวางแผนการผลิตและการขายอยู่แล้ว แต่พวกเขาใช้การบรรทุกรถยนต์ที่โรงงานใน MySklad โดยอัตโนมัติ นี่คือวิธีที่เราได้รับพื้นฐานแรกของ API จริง: การแลกเปลี่ยนระหว่างบริการของเรากับ ERP เกิดขึ้นโดยการส่งไฟล์ขนาดใหญ่พร้อมข้อมูลในเอกสารทุกประเภท
นี่เป็นตัวเลือกที่ดีสำหรับการแลกเปลี่ยนข้อมูลเป็นชุด แต่เมื่อรวมกับเอกสารแล้ว เราก็ต้องถ่ายโอนการพึ่งพา: ข้อมูลเกี่ยวกับสินค้า ผู้รับเหมา และคลังสินค้า ดัมพ์ดังกล่าวสร้างขึ้นได้ไม่ยากเมื่อส่งออก แต่การแยกวิเคราะห์เมื่อนำเข้านั้นค่อนข้างยากเนื่องจากข้อมูลทั้งหมดมาในแพ็คเกจเดียว: ทั้งเกี่ยวกับเอกสารใหม่และเกี่ยวกับเอกสารที่มีอยู่
XML API แรกใช้งานได้ไม่นาน สองปีต่อมาเราก็เริ่มสร้างมันขึ้นมาใหม่ แม้แต่ในช่วงเริ่มต้นของการทำงาน เราก็ทำผิดพลาดหลายประการเมื่อสร้างอินเทอร์เฟซซอฟต์แวร์
วิธีสร้าง XML API: ภาพประกอบจากสถาปนิกคนหนึ่งของเรา โดยวิธีการติดตามติดตามบทความของเขา
นี่คือข้อผิดพลาดหลักของเรา:
- มาร์กอัป JAXB ทำได้โดยตรงบน Entity Bean เราใช้ Hibernate เพื่อสื่อสารกับฐานข้อมูล และมาร์กอัป JAXB ถูกสร้างขึ้นสำหรับ bean เดียวกัน ข้อผิดพลาดนี้ปรากฏขึ้นแทบจะในทันที: การอัปเดตโครงสร้างข้อมูลใดๆ ส่งผลให้จำเป็นต้องแจ้งทุกคนที่ใช้ 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 RetailCRM เผยแพร่ไลบรารีบุคคลที่สามชุดแรกเพื่อเข้าถึง API ของเรา เริ่มมีการใช้งานค่อนข้างมากในขณะที่ความนิยมของบริการโดยรวมเพิ่มขึ้น แต่โหลดบน API ก็เพิ่มขึ้นเร็วกว่าโหลดบนเว็บอินเตอร์เฟส การเติบโตเพียงวันเดียวก็กลายเป็นภาระที่เพิ่มขึ้นอย่างรวดเร็ว
และการกระโดดครั้งนี้ ซึ่งระบุด้วยลูกศรด้านซ้าย ทำให้เซิร์ฟเวอร์ที่ให้บริการ API ของเราประหลาดใจอย่างยิ่ง เราใช้เวลาหนึ่งสัปดาห์เพื่อค้นหาว่าอะไรกันแน่ที่ทำให้เกิดภาระนี้ ปรากฎว่านี่เป็นคำขอเดียวกันที่ส่งไปยัง API ของเราจากส่วนหน้าของไคลเอ็นต์ ลูกค้าประมาณ 50 คนกินทุกอย่าง ตอนนั้นเองที่เราตระหนักถึงความผิดพลาดประการหนึ่งของเรา นั่นก็คือการไม่มีขีดจำกัดโดยสิ้นเชิง
ด้วยเหตุนี้ เราจึงได้จำกัดจำนวนคำขอพร้อมกัน ขณะนี้สามารถเปิดคำขอได้ไม่เกินสองคำขอพร้อมกันจากบัญชีเดียว ซึ่งเพียงพอแล้วสำหรับการทำงานในโหมดการจำลองแบบสำหรับการแลกเปลี่ยนข้อมูลในโหมดแบตช์ และผู้ที่ต้องการใช้เราเป็นแบ็กเอนด์ตั้งแต่นั้นเป็นต้นมา ถูกบังคับให้ปฏิบัติตามอัตราภาษีให้ดีขึ้น เนื่องจากพวกเขาแนะนำการทำงานกับหลายบัญชีในซอฟต์แวร์ของพวกเขา
มาเรียงลำดับกันดีกว่า
ตั้งแต่ปี 2014 ความต้องการ API ที่มีอยู่ได้กลายเป็นส่วนสำคัญของธุรกิจ และ API เองก็สร้างข้อมูลปริมาณมากที่สุดในการแลกเปลี่ยนข้อมูลกับลูกค้า ในปี 2015 เราได้เปิดตัวโครงการเพื่อล้างข้อมูล API เราเลือก JSON แทน XML เป็นรูปแบบ และเริ่มสร้างมันตามคุณสมบัติที่ระบุไว้ระหว่างการใช้งานเวอร์ชันก่อนหน้า:
- ความสามารถในการจัดการเวอร์ชัน การกำหนดเวอร์ชันช่วยให้คุณพัฒนาเวอร์ชันใหม่ได้โดยไม่ส่งผลกระทบต่อแอปพลิเคชันที่มีอยู่หรือรบกวนประสบการณ์ผู้ใช้
- ความสามารถสำหรับผู้ใช้ในการดูข้อมูลเมตาในการตอบกลับที่เขาได้รับ
- สามารถแลกเปลี่ยนเอกสารขนาดใหญ่ได้ หากเราประมวลผลเอกสารที่มีตำแหน่งมากกว่า 4-5 ตำแหน่ง สิ่งนี้จะกลายเป็นปัญหาสำหรับเซิร์ฟเวอร์: ธุรกรรมที่ยาว คำขอ http ที่ยาว เราสร้างกลไกพิเศษที่ช่วยให้คุณสามารถอัปเดตเอกสารเป็นบางส่วนและจัดการแต่ละตำแหน่งของเอกสารนี้โดยส่งไปยังเซิร์ฟเวอร์
- เครื่องมือสำหรับการจำลองแบบก็มีอยู่ในเวอร์ชันก่อนหน้าด้วย
- ขีดจำกัดการโหลดเปรียบเสมือนมรดกของคราดที่ถูกเหยียบในเวอร์ชันก่อนหน้า เราได้แนะนำการจำกัดจำนวนคำขอในช่วงเวลาหนึ่ง จำนวนคำขอแบบขนาน และคำขอจากที่อยู่ IP เดียว
ตั้งแต่นั้นเป็นต้นมา เราได้เผยแพร่ API เวอร์ชันรอง XNUMX เวอร์ชันและเปิดตัว API พิเศษหลายรายการ แต่แนวทางโดยรวมยังคงไม่เปลี่ยนแปลง รูปแบบการแลกเปลี่ยนที่อัปเดตและสถาปัตยกรรมใหม่ทำให้สามารถแก้ไขข้อบกพร่องใน API ได้เร็วขึ้นมาก
MySklad API วันนี้
ปัจจุบัน MySklad API สามารถแก้ปัญหาได้มากมาย:
- การแลกเปลี่ยนข้อมูลกับร้านค้าออนไลน์ ระบบบัญชี ธนาคาร
- การได้รับข้อมูลและรายงานจากการคำนวณ
- ใช้เป็นแบ็กเอนด์สำหรับแอปพลิเคชันไคลเอนต์ - แอปพลิเคชันมือถือและเครื่องบันทึกเงินสดบนเดสก์ท็อปของเราทำงานผ่าน API
- ส่งการแจ้งเตือนเกี่ยวกับการเปลี่ยนแปลงข้อมูลใน MySklad - webhooks;
- โทรศัพท์;
- ระบบความภักดี
อ้างอิงจาก API ของ Askar Rakhimberdiev ซึ่งเป็น CEO ของเรา ภายในสี่ชั่วโมง ฉันเขียนบอทโทรเลขเพื่อดึงของเหลือผ่าน API:
ตอนนี้ตัวเลขแห้ง
นี่คือสถิติของเราสำหรับ REST API เก่า:
- 400 บริษัท;
- ผู้ใช้ 600 ราย;
- 2 ล้านคำขอต่อวัน
- ปริมาณข้อมูลขาออก 200 GB/วัน
และนี่คือสิ่งที่เราคิดขึ้นมาสำหรับ MySklad API ทั้งหมด:
- การบูรณาการมากกว่า 70 รายการ (บางส่วนสามารถดูได้ที่นี่) );
- 8500 บริษัท;
- ผู้ใช้ 12 ราย;
- 46 ล้านคำขอต่อวัน
- ปริมาณข้อมูลขาออก 2 TB/วัน
มีอะไรต่อไป
แผนการพัฒนา API อยู่ระหว่างการหารืออย่างแข็งขัน เราพยายามคำนึงถึงประสบการณ์การดำเนินงานที่ผู้ใช้มอบให้เรา เราไม่สามารถทำทุกอย่างพร้อมกันได้เสมอไป แต่ API เวอร์ชันใหม่อยู่ใกล้แค่เอื้อมพร้อมข้อมูลเมตาที่สะดวกยิ่งขึ้นและโครงสร้างที่นุ่มนวลน้อยลง OAuth สำหรับการตรวจสอบสิทธิ์ และ API สำหรับแอปพลิเคชันที่สร้างไว้ในอินเทอร์เฟซ
คุณสามารถติดตามข่าวสารบนเว็บไซต์พิเศษสำหรับผู้พัฒนาการผสานรวมกับ MySklad: .
ที่มา: will.com