การอธิบาย API การซื้อขาย Forex: REST, WebSocket, FIX และ MT5

REST, WebSocket, FIX และ MT5 มักถูกนำเสนอเป็นสี่ API forex ที่แข่งขันกัน แต่จริงๆ แล้วไม่ใช่

REST มักเป็นวิธีที่สะอาดที่สุดในการร้องขอข้อมูลบัญชี โหลดประวัติ หรือส่งคำสั่งเป็นครั้งคราว WebSocket รักษาการเชื่อมต่อให้เปิดอยู่เพื่อให้ราคาสินค้าและการอัปเดตคำสั่งสามารถเข้ามาได้ตามที่เกิดขึ้น FIX เป็นมาตรฐานการส่งข้อความทางการเงินที่ใช้สำหรับการจัดการคำสั่ง รายงานการดำเนินการ และข้อมูลตลาดระหว่างระบบการซื้อขายระดับมืออาชีพ MT5 เป็นแพลตฟอร์มการซื้อขายที่มี API หลายตัวสำหรับงานที่แตกต่างกัน

นายหน้าสามารถใช้ทั้งสี่วิธี แอปพลิเคชันมือถือสามารถโหลดบัญชีผ่าน REST สตรีมราคาผ่าน WebSocket ส่งคำสั่งไปยัง MetaTrader 5 และจัดการการเปิดเผยภายนอกไปยัง ผู้ให้บริการสภาพคล่อง ผ่าน FIX แต่ละอินเทอร์เฟซอยู่ในส่วนที่แตกต่างกันของการซื้อขาย。

อินเทอร์เฟซ	รูปแบบการสื่อสาร	เหมาะสมที่สุด	ไม่เหมาะสม
REST API	ไคลเอนต์ส่งคำขอและได้รับการตอบสนอง	กระบวนการเข้าสู่ระบบ, บัญชี, สัญลักษณ์, ประวัติ, รายงาน และคำสั่งที่ความถี่ต่ำ	การสตรีมราคาต่อเนื่องผ่านการตรวจสอบซ้ำ
WebSocket API	ไคลเอนต์และเซิร์ฟเวอร์เปิดการเชื่อมต่อแบบสองทาง	ราคาแบบสด, ความลึก, สถานะคำสั่ง และเหตุการณ์บัญชี	การสอบถามประวัติศาสตร์ที่ยาวนานและบันทึกการจัดการที่เรียบง่าย
FIX API	สองระบบการซื้อขายแลกเปลี่ยนข้อความทางการเงินที่เป็นมาตรฐานภายในเซสชันที่จัดการ	การไหลของคำสั่งจากโบรกเกอร์ไปยัง LP, สถานที่และคำสั่งของสถาบัน	API สาธารณะง่ายๆ สำหรับแอปมือถือสำหรับผู้ค้าปลีก
MT5 APIs	หลายอินเทอร์เฟซรอบแพลตฟอร์ม MetaTrader 5	การจัดการโบรกเกอร์, การขยายแพลตฟอร์ม, เกตเวย์, รายงาน และการทำงานอัตโนมัติของเทอร์มินัล	โปรโตคอลสากลที่ไม่ขึ้นอยู่กับ MT5

วิธีที่ API เหล่านี้เข้ากับระบบการซื้อขายฟอเร็กซ์หนึ่งระบบ

ฉันมองสี่ชื่อว่าเป็นชั้นที่แตกต่างกัน

REST และ WebSocket มักจะอยู่ใกล้กับแอปพลิเคชันที่หันหน้าไปทางผู้ค้า FIX มักจะอยู่ลึกกว่าในโครงสร้างพื้นฐานการดำเนินการ MT5 อาจเป็นแพลตฟอร์มการซื้อขายในกลาง แต่ก็สามารถเชื่อมต่อกับเว็บไซต์ เครื่องมือภายใน และสถานที่ภายนอกผ่าน API ของตัวเองได้

How one forex order moves through the stack

One order. Five steps. From the trader’s app to execution and back.

01Order 02Live price 03Risk check 04Execution 05Confirmation

RESTFIXWebSocket

Trader appBUY 100K EUR/USD

Broker coreORDER #A-18427 / EUR/USD

API gatewayWaiting

Risk enginePending

Trading platform – MT5Ready

Execution routerPending

RESTWaiting for order

Liquidity providerPrice + fill

CRM / automationAccount and client data

Venue / exchangeMarket data and venues

1. The app sends the order to the broker through REST.
2. The liquidity provider sends prices to the broker, and WebSocket keeps the app current.
3. The broker checks the order and passes it to the trading platform.
4. The execution router sends the order to the liquidity provider through FIX.
5. The fill returns to the broker, then the app receives the confirmation through WebSocket.

เส้นทางที่แน่นอนจะแตกต่างกันไปตามโบรกเกอร์ แพลตฟอร์มบางแห่งเปิดเผยคำสั่งการซื้อขายผ่าน REST ขณะที่แพลตฟอร์มอื่นๆ จะส่งทั้งคำขอและเหตุการณ์ผ่าน WebSocket หรือ TCP แบบดิบ โบรกเกอร์ MT5 อาจใช้เกตเวย์ สะพาน หรือกลไกการซื้อขายภายในแทนที่จะส่งคำสั่งทุกคำสั่งไปยังผู้ให้สภาพคล่องโดยตรง

ดังนั้น แผนภาพควรอ่านว่าเป็นรูปแบบสถาปัตยกรรม ไม่ใช่การรับประกันว่าบร็อกเกอร์แต่ละรายจะประมวลผลการซื้อขายในลักษณะเดียวกัน

REST API ในการซื้อขายฟอเร็กซ์คืออะไร?

API REST เปิดเผยทรัพยากรผ่าน HTTP ลูกค้าส่งคำขอไปยังจุดสิ้นสุด และเซิร์ฟเวอร์ส่งกลับการตอบสนอง

การโทรทั่วไปมีลักษณะดังนี้:

• GET /accounts/417 เพื่อโหลดบัญชี;
• GET /orders?status=open เพื่อดึงคำสั่งซื้อที่เปิดอยู่;
• GET /candles?symbol=EURUSD&timeframe=1h เพื่อขอข้อมูลแท่งเทียนประวัติศาสตร์;
• POST /orders เพื่อส่งคำสั่งซื้อ;
• DELETE /orders/8921 เพื่อขอการยกเลิก.

URLs และวิธีการที่แน่นอนขึ้นอยู่กับผู้ให้บริการ แนวคิดที่มั่นคงคือการร้องขอและการตอบสนอง HTTP เองเป็นโปรโตคอลที่ไม่มีสถานะ ซึ่งหมายความว่าการร้องขอแต่ละครั้งสามารถเข้าใจได้ด้วยตนเอง ข้อกำหนด HTTP กำหนดความหมายเบื้องหลังวิธีการ รหัสสถานะ และการตอบสนอง

ที่ไหนที่ REST ทำงานได้ดี

REST เป็นทางเลือกที่เหมาะสมสำหรับข้อมูลที่เปลี่ยนแปลงเฉพาะเมื่อมีการร้องขอ:

• โปรไฟล์บัญชีและสิทธิ์;
• เครื่องมือที่มีอยู่และการตั้งค่าข้อตกลง;
• การฝากเงิน การถอนเงิน และรายงาน;
• คำสั่งประวัติศาสตร์, ข้อตกลงและเทียน;
• การตั้งค่ากลยุทธ์;
• การสร้างหรือยกเลิกคำสั่งซื้อเมื่อ API รองรับการซื้อขาย.

การตรวจสอบ บันทึก แคช และรวมเข้ากับโครงสร้างพื้นฐานเว็บทั่วไปนั้นทำได้ง่าย ทีมพัฒนาส่วนใหญ่ already รู้วิธีการทำงานกับ HTTP และ JSON.

จุดเริ่มต้นที่ REST เริ่มเครียด

REST ไม่ได้ช้าโดยธรรมชาติ API REST ที่สร้างขึ้นมาได้ดีสามารถตอบสนองได้อย่างรวดเร็วพอสำหรับการทำงานทางการค้าหลายๆ อย่าง ปัญหาจะเกิดขึ้นเมื่อไคลเอนต์ต้องถามคำถามเดียวกันหลายร้อยครั้ง:

คู่เงิน EUR/USD มีการเปลี่ยนแปลงหรือไม่?

คำสั่งซื้อของฉันเสร็จสมบูรณ์หรือยัง?

ขอบของฉันเปลี่ยนไปหรือเปล่า?

การสำรวจความคิดเห็นนั้นสร้างคำขอซ้ำๆ, หัวเรื่อง และการทำงานของเซิร์ฟเวอร์ มันยังสามารถทำให้เกิดช่องว่างระหว่างการสำรวจความคิดเห็น หากแอปขอราคาเพียงครั้งเดียวในทุกๆ วินาที มันจะไม่รู้ว่าเกิดอะไรขึ้นระหว่างคำขอนั้น

ฉันใช้ REST สำหรับภาพถ่ายและคำสั่ง ฉันไม่ใช้การตรวจสอบข้อมูลแบบ polling เป็นแหล่งข้อมูลหลักของสถานะการซื้อขายสดเมื่อมีการสตรีมเหตุการณ์ที่เหมาะสมอยู่

WebSocket API คืออะไรในตลาดฟอเร็กซ์?

WebSocket สร้างการเชื่อมต่อแบบสองทางที่มีความคงอยู่ระหว่างไคลเอนต์และเซิร์ฟเวอร์ หลังจากการจับมือเปิดแล้ว ฝ่ายใดฝ่ายหนึ่งสามารถส่งข้อความได้โดยไม่ต้องรอคำขอ HTTP ใหม่ พฤติกรรมดังกล่าวถูกกำหนดไว้ใน โปรโตคอล WebSocket.

ในแอปการซื้อขาย ลูกค้าสามารถสมัครสมาชิก EURUSD ได้ครั้งเดียว จากนั้นเซิร์ฟเวอร์จะส่งการอัปเดตการเสนอราคาที่อนุญาตแต่ละรายการผ่านการเชื่อมต่อที่เปิดอยู่ สตรีมเดียวกันอาจส่งการยืนยันคำสั่ง การเติมเต็ม การเปลี่ยนแปลงยอดคงเหลือ และเหตุการณ์มาร์จิน

ที่ไหนที่ WebSocket ทำงานได้ดี

API WebSocket ของฟอเร็กซ์เหมาะสำหรับข้อมูลที่เปลี่ยนแปลงอย่างต่อเนื่อง:

• ราคาเสนอซื้อและราคาเสนอขาย;
• การปรับปรุงแผนภูมิ;
• ความลึกของตลาด;
• การยอมรับคำสั่งซื้อ, การปฏิเสธและการเติมเต็ม;
• การเปลี่ยนแปลงตำแหน่งและบัญชี;
• คำเตือนเกี่ยวกับมาร์จิ้น;
• สถานะการซื้อขาย.

ลูกค้าได้รับการเปลี่ยนแปลงแทนที่จะต้องร้องขอซ้ำแล้วซ้ำอีก ซึ่งช่วยลดการสอบถามและทำให้ส่วนติดต่อรู้สึกเหมือนมีชีวิต.

การเชื่อมต่อที่เปิดไม่เพียงพอ

WebSocket ไม่ทำให้แอปพลิเคชันการค้ามีความน่าเชื่อถือด้วยตัวมันเอง

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

ฉันมองหากลไกการฟื้นฟูห้าอย่าง:

1. การเต้นของหัวใจ. ลูกค้าต้องรู้ว่าการเชื่อมต่อนั้นยังมีชีวิตอยู่หรือไม่.
2. สถานะข้อมูลเก่า. อินเทอร์เฟซต้องหยุดแสดงคำคมเก่าเป็นปัจจุบัน.
3. เชื่อมต่อใหม่และสมัครสมาชิกอีกครั้ง ลูกค้าจำเป็นต้องกู้คืนสตรีมที่ต้องการทั้งหมด
4. สแน็ปช็อตพร้อมอัปเดต. หลังจากเชื่อมต่ออีกครั้ง ให้โหลดสแน็ปช็อต REST ปัจจุบันก่อนที่จะนำเหตุการณ์ใหม่มาใช้.
5. ลำดับหรือเคอร์เซอร์ หาก API มีตัวระบุเหตุการณ์ ให้ใช้เพื่อตรวจสอบช่องว่างและรายการที่ซ้ำกัน

FIX API คืออะไรในตลาดฟอเร็กซ์?

FIX ย่อมาจาก Financial Information eXchange มันกำหนดข้อความที่ระบบการเงินใช้ในการสื่อสารเกี่ยวกับคำสั่ง การดำเนินการ การเสนอราคา ข้อมูลตลาด และเซสชันต่างๆ

คำสั่งใหม่ ตัวอย่างเช่น จะติดตามประเภทข้อความที่แชร์ที่มีฟิลด์ที่ตั้งชื่อไว้สำหรับรายละเอียด เช่น เครื่องมือ, ด้าน, ปริมาณ, ประเภทคำสั่ง และ ID คำสั่งของลูกค้า.

การแก้ไขเป็นสิ่งที่พบได้ทั่วไประหว่าง:

• โบรกเกอร์และผู้ให้บริการสภาพคล่อง;
• โบรกเกอร์และตลาดหลักทรัพย์หรือสถานที่อื่น ๆ;
• ลูกค้าสถาบันและนายหน้า;
• ระบบการจัดการคำสั่งซื้อและระบบการดำเนินการ.

ทำไมบริษัทถึงใช้ FIX

FIX ให้ทั้งสองฝ่ายมีภาษาการเงินร่วมกันและวิธีที่มีระเบียบในการจัดการการเชื่อมต่อ มันไม่ได้หมายความว่าเป็น API ที่เร็วที่สุดโดยอัตโนมัติ; เครื่องยนต์ เครือข่าย และการตั้งค่าฝ่ายตรงข้ามยังคงกำหนดประสิทธิภาพ

เซสชัน FIX จะติดตามหมายเลขลำดับข้อความ หากด้านใดด้านหนึ่งได้รับข้อความ 208 หลังจากข้อความ 206 จะสามารถตรวจจับได้ว่า 207 ขาดหายไปและขอให้ส่งใหม่ การตรวจสอบและการขอทดสอบช่วยให้ทั้งสองฝ่ายติดตามเซสชันได้

สิ่งนี้มีความสำคัญเมื่อข้อความแสดงถึงคำสั่งและการเติมเต็ม “การเชื่อมต่อกลับมาแล้ว” ไม่เพียงพอ ระบบทั้งสองต้องเห็นพ้องกันว่าข้อความใดถูกประมวลผลแล้ว

สิ่งที่ FIX ไม่สามารถแก้ไขได้

FIX ไม่ได้ลบงานการรวมระบบออก.

คู่สัญญาทั้งสองยังต้องตกลงกันเกี่ยวกับ:

• รุ่น FIX และข้อความที่รองรับ;
• ฟิลด์ที่จำเป็น, ฟิลด์ที่เลือกได้และฟิลด์ที่กำหนดเอง;
• ชื่อสัญลักษณ์และตัวระบุเครื่องมือ;
• ประเภทคำสั่งที่รองรับและค่าระยะเวลาที่มีผล;
• ความแม่นยำของราคาและปริมาณ;
• เซสชันการซื้อขายและช่วงเวลาบำรุงรักษา;
• กฎการรีเซ็ตลำดับและการส่งใหม่;
• กรณีทดสอบการรับรอง;
• ความปลอดภัยของเครือข่ายและที่อยู่ IP ที่อนุญาต.

ฉันไม่เคยรับ “FIX supported” เป็นคำตอบการรวมระบบที่สมบูรณ์ ฉันขอให้มีการระบุข้อกำหนดของคู่ค้าและแผนการรับรอง มาตรฐานที่มีกฎเกณฑ์ที่แตกต่างกันในแต่ละด้านยังคงต้องมีการแมปและการทดสอบ

“MT5 API” หมายถึงอะไร?

MetaTrader 5 เป็นแพลตฟอร์ม ไม่ใช่โปรโตคอล API ตัวเดียว MetaQuotes มีรายการหลายอินเทอร์เฟซสำหรับโบรกเกอร์ รวมถึง Manager, Gateway, Report, Server และ Web APIs แต่ละตัวมีบทบาทที่แตกต่างกันในสภาพแวดล้อม MT5

ผู้จัดการ API

API ผู้จัดการเป็นเครื่องมือสำหรับการบริหารจัดการและการจัดการในด้านโบรกเกอร์ โบรกเกอร์สามารถใช้มันเพื่อสร้างยูทิลิตี้ภายในรอบบัญชี กลุ่ม การดำเนินการซื้อขาย และการบริหารจัดการแพลตฟอร์ม.

นี่ไม่ใช่ผลิตภัณฑ์เดียวกับ API key ของผู้ค้าปลีก การเข้าถึง การอนุญาต และการดำเนินการที่รองรับเป็นของการตั้งค่า MetaTrader ของโบรกเกอร์

เกตเวย์ API

Gateway API ใช้สำหรับเชื่อมต่อ MetaTrader 5 กับระบบการซื้อขายภายนอกและข้อมูลการซื้อขาย MetaQuotes อธิบายว่าเกตเวย์เป็นปลั๊กอินของแพลตฟอร์มที่จัดการการโต้ตอบกับตลาดหรือระบบที่เชื่อมต่ออื่น ๆ

สิ่งนี้อยู่ใกล้กับการเชื่อมต่อกับตลาดมากกว่าจุดสิ้นสุด REST ที่มุ่งหน้าไปยังผู้ค้า

เว็บ, รายงาน และ API เซิร์ฟเวอร์

MetaQuotes อธิบาย Web API ว่าเป็นส่วนเชื่อมต่อสำหรับการเชื่อมโยงแพลตฟอร์มกับทรัพยากรและบริการเว็บของโบรกเกอร์ Report API ขยายการรายงานเซิร์ฟเวอร์ Server API ช่วยให้ผู้ดำเนินการแพลตฟอร์มสามารถเพิ่มฟังก์ชันการทำงานของเซิร์ฟเวอร์การค้าและเซิร์ฟเวอร์ประวัติได้

ชื่อของพวกเขาอาจดูเข้าใจได้ง่าย แต่ขอบเขตและความพร้อมใช้งานต้องตรวจสอบในใบอนุญาตของโบรกเกอร์และเอกสารทางเทคนิค

MQL5

MQL5 คือภาษาและสภาพแวดล้อมการโปรแกรมที่ใช้ภายใน MetaTrader 5 นักเทรดและนักพัฒนาสร้างที่ปรึกษาผู้เชี่ยวชาญ ตัวชี้วัด สคริปต์ และบริการที่ทำงานร่วมกับเทอร์มินัล

นี่คือเส้นทางพื้นเมืองสำหรับกลยุทธ์อัตโนมัติที่ต้องการข้อมูลกราฟ, ตัวชี้วัดและฟังก์ชันการซื้อขายภายใน MT5 มันไม่ใช่โปรโตคอลระหว่างโบรกเกอร์กับผู้ให้สภาพคล่อง.

การรวม Python กับ MetaTrader 5

แพ็คเกจ MetaTrader5 สำหรับภาษา Python อย่างเป็นทางการช่วยให้โปรแกรม Python สามารถอ่านข้อมูลและส่งคำขอการซื้อขายผ่านเทอร์มินัล MetaTrader 5 คำสำคัญคือ ผ่านเทอร์มินัล.

เอกสาร Python อย่างเป็นทางการ ระบุว่าชุดโปรแกรมสื่อสารโดยตรงกับเทอร์มินัลโดยใช้การสื่อสารระหว่างกระบวนการ มันไม่ได้ให้การเชื่อมต่อโดยตรงกับเซิร์ฟเวอร์ MT5 ของโบรกเกอร์แก่บริการคลาวด์ที่กำหนดเอง

ความแตกต่างนั้นเปลี่ยนแปลงการนำไปใช้งาน กลยุทธ์ Python ต้องการสภาพแวดล้อมของเทอร์มินัลที่เข้ากันได้, เซสชันบัญชี, การตรวจสอบ และแผนสำหรับการเริ่มต้นเทอร์มินัลใหม่ มันไม่ควรถูกออกแบบมาเหมือนกับว่า pip install MetaTrader5 สร้าง API โบรกเกอร์ฝั่งเซิร์ฟเวอร์

คำสั่งหนึ่งสามารถผ่านหลาย API ได้

สมมติว่าผู้ค้าซื้อ 100,000 หน่วยของ EUR/USD ในแอปมือถือของโบรกเกอร์。

1. แอปโหลดบัญชี, การระบุสัญลักษณ์ และสิทธิ์ผ่าน REST.
2. มันรับการเสนอราคาและราคาขอปัจจุบันผ่าน WebSocket。
3. ผู้ค้าแตะที่ ซื้อ แอปจะส่งคำสั่งซื้อพร้อมกับหมายเลขคำสั่งซื้อของลูกค้าที่ไม่ซ้ำกัน
4. บริการความเสี่ยงของโบรกเกอร์ตรวจสอบมาร์จิ้น ขีดจำกัด และสถานะตลาด
5. แพลตฟอร์มการซื้อขายจะยอมรับหรือปฏิเสธคำสั่งนั้น แพลตฟอร์มนั้นอาจเป็น MT5
6. ขึ้นอยู่กับรูปแบบการดำเนินการของโบรกเกอร์ การเปิดเผยภายนอกอาจถูกส่งไปยังผู้ให้บริการสภาพคล่องผ่าน FIX, เกตเวย์ หรือการเชื่อมต่ออื่น ๆ
7. รายงานการดำเนินการถูกส่งกลับผ่านสแต็ก。
8. แอปได้รับคำสั่งซื้อที่อัปเดต ตำแหน่ง และยอดคงเหลือผ่านสตรีมเหตุการณ์ของมัน

REST ไม่ได้แข่งขันกับ FIX ในลำดับนี้ พวกเขาทำงานที่ขอบเขตที่แตกต่างกัน

กรณีหมดเวลา ที่เปิดเผย API ที่อ่อนแอ

ส่วนที่ยากของ API การสั่งซื้อคือการไม่ได้ส่งคำขอ แต่เป็นการรู้ว่าเกิดอะไรขึ้นเมื่อการตอบกลับหายไป

สมมติว่าแอปส่งคำสั่งนี้:

ซื้อ EURUSD, clientOrderId = mobile-84721

การร้องขอหมดเวลา มีสองความเป็นไปได้:

• นายหน้าซื้อขายหลักทรัพย์ไม่เคยได้รับมัน;
• นายหน้ารับมัน แต่การตอบสนองไม่ถึงแอป

การส่งการซื้อขายเดียวกันโดยไม่คิดให้ดีก็อาจสร้างตำแหน่งสองตำแหน่งขึ้นมาได้

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

1. รักษา ID คำสั่งซื้อของลูกค้าไว้เหมือนเดิม.
2. สอบถามสถานะคำสั่งที่ได้รับอนุญาตหรือรอเหตุการณ์คำสั่ง
3. ให้เซิร์ฟเวอร์ปฏิเสธหรือกำจัดคำสั่งที่ซ้ำกันด้วย ID เดียวกัน
4. ตรวจสอบคำสั่งซื้อสุดท้ายและบันทึกข้อมูลก่อนที่จะเปิดใช้งานการลองใหม่อีกครั้ง.

นี่คือเหตุผลที่ฉันถามผู้ให้บริการ API เกี่ยวกับความเป็นอิสระก่อนที่ฉันจะถามเกี่ยวกับอัตราการร้องขอหัวข้อข่าว จุดสิ้นสุดที่รวดเร็วที่สามารถทำซ้ำการกระทำทางการเงินหลังจากเวลาหยุดทำงานไม่ใช่จุดสิ้นสุดการซื้อขายที่ดี

REST กับ WebSocket กับ FIX กับ MT5 ตามกรณีการใช้งาน

ความต้องการ	ส่วนต่อประสานที่ฉันจะตรวจสอบก่อน	เหตุผล
เว็บไซต์นายหน้าที่แสดงประวัติบัญชี	REST	คำค้นหาที่ง่าย การตรวจสอบสิทธิ์ที่คุ้นเคย และการตอบสนองที่ชัดเจน
รายการเฝ้าดูสดในเว็บหรือแอปมือถือ	WebSocket	ราคามาถึงเป็นเหตุการณ์โดยไม่ต้องตรวจสอบอย่างต่อเนื่อง
การป้อนคำสั่งค้าปลีกจากแอปที่กำหนดเอง	คำสั่ง REST บวกสถานะ WebSocket	การส่งคำสั่งที่ชัดเจนพร้อมการยืนยันสดและการอัปเดตการเติมเต็ม
การเชื่อมต่อนายหน้ากับผู้ให้บริการสภาพคล่อง	FIX หรือการเชื่อมต่อที่ได้รับการรับรองจากผู้ให้บริการ	กระบวนการสั่งซื้อและการดำเนินการมาตรฐานระหว่างระบบการซื้อขาย
การจัดการนายหน้าเกี่ยวกับ MT5	MT5 Manager API	สร้างขึ้นสำหรับเครื่องมือการจัดการด้านแพลตฟอร์ม
การเชื่อมต่อ MT5 ที่กำหนดเองกับสถานที่	MT5 Gateway API หรือการตั้งค่าบริดจ์/เกตเวย์ที่ผ่านการทดสอบ	ออกแบบมาเพื่อการเชื่อมต่อทางการตลาดของแพลตฟอร์ม
ที่ปรึกษาผู้เชี่ยวชาญที่ทำงานใน MT5	MQL5	การทำงานอัตโนมัติและสภาพแวดล้อมการทดสอบที่เป็นธรรมชาติ
การวิเคราะห์และการดำเนินการ Python ผ่านเทอร์มินัล MT5	แพ็คเกจ Python MetaTrader 5	ให้การเข้าถึงข้อมูลเทอร์มินัลและฟังก์ชันการซื้อขายสำหรับ Python
ชุดข้อมูลการวิจัยประวัติศาสตร์	REST หรือการส่งออกข้อมูลจำนวนมาก	การแบ่งหน้าที่ง่ายขึ้น ช่วงวันที่ และการดึงข้อมูลที่สามารถทำซ้ำได้

ตารางนี้เป็นจุดเริ่มต้น ตัวเลือกสุดท้ายขึ้นอยู่กับ API ที่แท้จริงของผู้ให้บริการ ขีดจำกัดอัตรา การตรวจสอบสิทธิ์ ประเภทคำสั่งที่รองรับ และการรับประกันบริการ

คำถามที่ฉันถามก่อนเลือก API การเทรดฟอเร็กซ์

ข้อมูลตลาด

• ฟีดเป็นแบบติ๊กต่อติ๊ก, รวมกันหรือถูกสุ่มตัวอย่าง?
• เวลาประมูลและเสนอถูกสร้างขึ้นที่ต้นทางหรือเมื่อส่งมอบ?
• สตรีมมีหมายเลขลำดับรวมอยู่ด้วยหรือไม่?
• ลูกค้าจะกู้คืนข้อมูลได้อย่างไรหลังจากการเชื่อมต่อขาด?
• การระบุสัญลักษณ์มีการเวอร์ชันเมื่อการตั้งค่าในสัญญาเปลี่ยนแปลงหรือไม่?

คำสั่งซื้อ

• มีหมายเลขคำสั่งซื้อของลูกค้าที่ไม่ซ้ำกันหรือไม่?
• คำสั่งสร้างและยกเลิกเป็นอิดempotent หรือไม่?
• API สามารถรายงานการเติมบางส่วนและรายงานการดำเนินการหลายรายการได้หรือไม่?
• บันทึกใดที่เป็นอำนาจหลังจากหมดเวลา?
• คำสั่งที่ถูกปฏิเสธ หมดอายุ และถูกแทนที่ แสดงอย่างไร?

การดำเนินงาน

• ข้อกำหนด ข้อสมัครสมาชิก และขีดจำกัดการเชื่อมต่อคืออะไร?
• สภาพแวดล้อมการสาธิตและการถ่ายทอดสดมีความเท่าเทียมกันในด้านพฤติกรรมหรือไม่?
• มีหน้าสถานะและประกาศการบำรุงรักษาที่กำหนดไว้หรือไม่?
• สามารถเชื่อมโยงบันทึกได้หรือไม่ระหว่างลูกค้า โบรกเกอร์ และสถานที่?
• การเปลี่ยนแปลงที่ทำลายล้างได้รับการจัดทำเวอร์ชันและประกาศอย่างไร?

ความปลอดภัย

• สิทธิ์ใดบ้างที่สามารถจำกัดต่อแอปพลิเคชันหรือโทเคน?
• การหมุนเวียนและเพิกถอนข้อมูลรับรองทำอย่างไร?
• มีการรองรับ IP allowlists, TLS และข้อมูลรับรองการผลิตแยกต่างหากหรือไม่?
• บริการหนึ่งสามารถอ่านข้อมูลโดยไม่ต้องได้รับอนุญาตการซื้อขายได้หรือไม่?
• การกระทำที่มีสิทธิพิเศษทุกครั้งจะถูกบันทึกลงในบันทึกการตรวจสอบหรือไม่?

คำตอบบอกฉันมากกว่าป้ายกำกับบน API สอง REST API อาจแตกต่างกันมากในด้านคุณภาพที่ใช้งานได้มากกว่า REST และ WebSocket

โบรกเกอร์ควรกำหนดอะไรบ้างก่อนการรวมระบบ

โครงการ API มักจะกลายเป็นเรื่องยากเมื่อความเป็นเจ้าของไม่ชัดเจน

กำหนดจุดเหล่านี้ก่อนเริ่มการพัฒนา:

1. ระบบการบันทึก. ระบบใดเป็นเจ้าของคำสั่ง, การเติม, ยอดคงเหลือ และตำแหน่ง?
2. ลำดับเหตุการณ์. การจัดการกับข้อความที่ซ้ำกัน ข้อความที่ล่าช้า และการอัปเดตที่ไม่เป็นระเบียบเป็นอย่างไร?
3. การกู้คืน. สแนปชอตใดถูกโหลดหลังจากการเชื่อมต่อใหม่ และจากเคอร์เซอร์ใดที่เหตุการณ์เริ่มต้นขึ้น?
4. ขอบเขตความเสี่ยง. การตรวจสอบใดบ้างที่ทำก่อนที่คำสั่งจะไปถึงแพลตฟอร์มหรือสถานที่?
5. แบบจำลองสัญลักษณ์. ใครเป็นผู้กำหนดชื่อ ขนาดสัญญา เซสชัน และความแม่นยำของราคา?
6. บันทึกการตรวจสอบ. สามารถติดตามการกระทำของลูกค้าจากแอปไปยังรายงานการดำเนินการขั้นสุดท้ายได้หรือไม่?

นี่คือจุดที่การตัดสินใจเกี่ยวกับแพลตฟอร์มกลายเป็นการตัดสินใจในการดำเนินงาน โครงสร้างพื้นฐานการค้าของ Quadcode นำแพลตฟอร์มการซื้อขาย, แอปพลิเคชันของลูกค้า, CRM, แผนกหลัง, ความเสี่ยง และการรวมระบบเข้าสู่สภาพแวดล้อมเดียวกัน การเชื่อมต่อ REST, สตรีมมิ่ง, MT5 หรือสภาพคล่องที่จำเป็นควรเขียนลงในแบบการออกแบบโซลูชันและทดสอบกับการไหลของคำสั่งของโบรกเกอร์เอง

คำตอบสุดท้าย

ใช้ REST สำหรับคำขอที่ชัดเจน, สแนปช็อตและบันทึก ใช้ WebSocket เมื่อแอปพลิเคชันต้องรับการเปลี่ยนแปลงแบบเรียลไทม์ ใช้ FIX สำหรับการสื่อสารการซื้อขายที่มีมาตรฐานระหว่างระบบมืออาชีพ ใช้ส่วนติดต่อ MT5 ที่เกี่ยวข้องเมื่อ MetaTrader 5 เป็นส่วนหนึ่งของแพลตฟอร์ม

ผลิตภัณฑ์ฟอเร็กซ์ส่วนใหญ่ต้องการการรวมกัน หลังจากเกิดการขัดข้องของเครือข่าย สถาปัตยกรรมที่ดีสามารถตอบคำถามสามข้อ: รับคำสั่งแล้วหรือยัง? มันถูกดำเนินการแล้วหรือยัง? ทุกระบบที่เชื่อมต่อในขณะนี้เห็นด้วยกับผลลัพธ์หรือไม่?