Forex 거래 API 설명: REST, WebSocket, FIX 및 MT5

REST, WebSocket, FIX 및 MT5는 종종 네 가지 경쟁 외환 API로 소개됩니다. 그렇지 않습니다.

REST는 일반적으로 계좌 데이터 요청, 로드 이력 또는 간헐적인 명령을 전송하는 가장 깔끔한 방법입니다. WebSocket은 연결을 유지하여 가격 및 주문 업데이트가 발생하는 대로 도착할 수 있도록 합니다. FIX는 전문 거래 시스템 간의 주문 라우팅, 실행 보고서 및 시장 데이터를 위한 금융 메시징 표준입니다. MT5는 다양한 작업을 위한 여러 API를 갖춘 거래 플랫폼입니다.

브로커는 네 가지 모두를 사용할 수 있습니다. 모바일 앱은 REST를 통해 계정을 로드하고, WebSocket을 통해 가격을 스트리밍하며, 주문을 MetaTrader 5로 보내고, FIX를 통해 외부 노출을 유동성 공급자로 라우팅할 수 있습니다. 각 인터페이스는 거래의 다른 부분에 속합니다.

인터페이스	통신 패턴	적합성	부적합성
REST API	클라이언트가 요청을 보내고 응답을 받음	로그인 흐름, 계정, 심볼, 이력, 보고서 및 저주파 명령	반복 폴링을 통한 연속 가격 스트리밍
WebSocket API	클라이언트와 서버가 양방향 연결을 유지함	실시간 견적, 깊이, 주문 상태 및 계정 이벤트	긴 역사적 쿼리 및 간단한 관리 기록
FIX API	두 거래 시스템이 관리 세션 내에서 표준화된 금융 메시지를 교환함	브로커-대출자, 장소 및 기관 주문 흐름	소매 모바일 앱을 위한 간단한 공개 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란 무엇인가요?

REST API는 HTTP를 통해 리소스를 노출합니다. 클라이언트는 엔드포인트에 요청을 보내고, 서버는 응답을 반환합니다.

전형적인 호출은 다음과 같습니다:

• GET /accounts/417로 계정을 로드합니다;
• GET /orders?status=open를 사용하여 열린 주문을 검색합니다;
• GET /candles?symbol=EURUSD&timeframe=1h를 사용하여 과거 막대 차트를 요청합니다;
• POST /orders를 사용하여 주문을 제출합니다;
• DELETE /orders/8921를 취소 요청으로 사용합니다.

정확한 URL과 방법은 제공자에 따라 다릅니다. 안정적인 개념은 요청과 응답입니다. HTTP 자체는 상태 비저장 프로토콜로, 이는 각 요청이 독립적으로 이해될 수 있음을 의미합니다. HTTP 명세는 방법, 상태 코드 및 응답 뒤에 있는 의미를 정의합니다.

REST가 잘 작동하는 곳

REST는 요청할 때만 변경되는 데이터에 대한 실용적인 선택입니다:

• 계정 프로필 및 권한;
• 사용 가능한 악기 및 계약 설정;
• 예치금, 출금 및 보고서;
• 역사적 주문, 거래 및 촛대;
• 전략 설정;
• API가 거래를 지원할 때 주문을 생성하거나 취소합니다.

일반적인 웹 인프라와 검사, 기록, 캐시 및 통합하는 것은 쉽습니다. 대부분의 개발 팀은 이미 HTTP와 JSON을 다루는 방법을 알고 있습니다.

REST가 한계에 다다르는 곳

REST는 본질적으로 느리지 않습니다. 잘 구축된 REST API는 많은 거래 워크플로우에 충분히 빠르게 응답할 수 있습니다. 문제는 클라이언트가 같은 질문을 수백 번 해야 할 때 발생합니다:

EUR/USD가 변경되었나요?

내 주문이 완료되었나요?

내 마진이 변경되었나요?

그 폴링은 반복적인 요청, 헤더 및 서버 작업을 생성합니다. 또한 폴 사이에 간격을 남길 수 있습니다. 앱이 초당 한 번 가격을 요청하면, 그 요청 사이에 무슨 일이 있었는지 알지 못합니다.

나는 스냅샷과 명령을 위해 REST를 사용한다. 적절한 이벤트 스트림이 존재할 때 실시간 거래 상태의 주요 소스로 폴링을 사용하지 않는다.

외환 거래에서 WebSocket API란 무엇인가요?

웹소켓은 클라이언트와 서버 간에 하나의 지속적이고 양방향 연결을 생성합니다. 개방 핸드셰이크 후, 어느 쪽이든 새로운 HTTP 요청을 기다리지 않고 메시지를 보낼 수 있습니다. 그 동작은 웹소켓 프로토콜에서 정의되어 있습니다.

거래 앱에서 클라이언트는 EURUSD에 한 번 구독할 수 있습니다. 그런 다음 서버는 열린 연결을 통해 각 허용된 견적 업데이트를 푸시합니다. 같은 스트림은 주문 확인, 체결, 잔액 변경 및 마진 이벤트를 포함할 수 있습니다.

웹소켓이 잘 작동하는 곳

외환 WebSocket API는 지속적으로 변하는 데이터에 적합합니다:

• 매수 및 매도 가격;
• 차트 업데이트;
• 시장 깊이;
• 주문 수락, 거부 및 체결;
• 위치 및 계정 변경;
• 여백 경고;
• 거래 세션 상태.

클라이언트는 반복적으로 요청하는 대신 변경 사항을 받습니다. 이는 폴링을 줄이고 인터페이스가 실시간으로 느껴지게 합니다.

열린 연결만으로는 충분하지 않다

웹소켓은 자체적으로 거래 애플리케이션을 신뢰할 수 있게 만들지 않습니다.

전화가 네트워크를 변경합니다. 노트북이 잠듭니다. 프록시가 유휴 연결을 종료합니다. 서버가 재시작됩니다. 인터페이스가 인식하기 전에 메시지가 도착하지 않을 수 있습니다.

저는 다섯 가지 회복 메커니즘을 찾습니다:

1. 심장 박동. 클라이언트는 연결이 여전히 활성 상태인지 알아야 합니다.
2. 오래된 데이터 상태. 인터페이스는 현재로서 오래된 인용을 제시하는 것을 중단해야 합니다.
3. 다시 연결하고 재구독하십시오. 클라이언트는 모든 필요한 스트림을 복원해야 합니다.
4. 스냅샷 및 업데이트. 재연결한 후, 새로운 이벤트를 적용하기 전에 현재 REST 스냅샷을 로드하세요.
5. 시퀀스 또는 커서. API가 이벤트 식별자를 제공하는 경우 이를 사용하여 간격과 중복을 감지하십시오.

외환 거래에서 FIX API란 무엇인가요?

FIX는 금융 정보 교환(Financial Information eXchange)의 약자입니다. 이는 금융 시스템이 주문, 실행, 견적, 시장 데이터 및 세션에 대해 소통하는 데 사용하는 메시지를 정의합니다.

예를 들어, 새로운 주문은 악기, 매수/매도, 수량, 주문 유형 및 고객 주문 ID와 같은 세부 정보를 위한 명명된 필드를 가진 공유 메시지 유형을 따릅니다.

FIX는 다음과 같은 것들 사이에 공통적입니다:

• 중개인 및 유동성 제공자;
• 브로커 및 거래소 또는 기타 장소;
• 기관 고객 및 중개인;
• 주문 관리 시스템 및 실행 시스템.

기업이 FIX를 사용하는 이유

FIX는 양측에 공통의 금융 언어와 연결을 관리하는 규율 있는 방법을 제공합니다. 이는 자동으로 가장 빠른 API가 아니며, 엔진, 네트워크 및 상대방 설정이 여전히 성능을 결정합니다.

FIX 세션은 메시지 순서 번호를 추적합니다. 한쪽에서 메시지 206 이후에 메시지 208을 수신하면 207이 누락되었음을 감지하고 재전송을 요청할 수 있습니다. 하트비트 및 테스트 요청은 양측이 세션을 모니터링하는 데 도움을 줍니다.

메시지가 주문 및 체결을 나타낼 때 이는 중요합니다. “연결이 복원되었습니다”는 충분하지 않습니다. 두 시스템은 어떤 메시지가 처리되었는지에 대해 합의해야 합니다.

FIX가 해결하지 않는 것

FIX는 통합 작업을 제거하지 않습니다.

두 당사자는 여전히 다음 사항에 합의해야 합니다:

• 수정된 FIX 버전 및 지원되는 메시지;
• 필수, 선택 및 사용자 정의 필드;
• 기호 이름 및 악기 식별자;
• 지원되는 주문 유형 및 유효 기간 값;
• 가격 및 수량 정밀도;
• 거래 세션 및 유지 보수 시간;
• 시퀀스 재설정 및 재전송 규칙;
• 인증 테스트 케이스;
• 네트워크 보안 및 허용된 IP 주소.

나는 “FIX 지원”을 완전한 통합 답변으로 받아들이지 않는다. 나는 상대방의 사양 및 인증 계획을 요청한다. 각 측면에서 서로 다른 필드 규칙이 있는 표준은 여전히 매핑 및 테스트가 필요하다.

“MT5 API”는 무엇을 의미하나요?

메타트레이더 5는 플랫폼이며, 하나의 API 프로토콜이 아닙니다. 메타쿼트는 브로커를 위한 여러 인터페이스를 나열합니다, 관리자, 게이트웨이, 보고서, 서버 및 웹 API를 포함하여. 각 인터페이스는 MT5 환경에서 다른 역할을 수행합니다.

매니저 API

관리자 API는 중개인 측의 관리 및 관리 도구를 위한 것입니다. 중개인은 이를 사용하여 계정, 그룹, 거래 운영 및 플랫폼 관리 주변에 내부 유틸리티를 구축할 수 있습니다.

이것은 소매 거래자의 API 키와 동일한 제품이 아닙니다. 접근, 라이센스 및 지원되는 운영은 중개인의 MetaTrader 설정에 속합니다.

게이트웨이 API

게이트웨이 API는 MetaTrader 5를 외부 거래 시스템 및 데이터 피드와 연결하는 데 사용됩니다. MetaQuotes는 게이트웨이를 거래소 또는 다른 연결된 시스템과의 상호 작용을 처리하는 플랫폼 플러그인으로 설명합니다.

이것은 거래자 대면 REST 엔드포인트보다 시장 연결성과 훨씬 더 가까이 위치해 있습니다.

웹, 보고서 및 서버 API

메타쿼츠는 웹 API를 브로커의 웹 리소스 및 서비스와 플랫폼을 연결하는 인터페이스로 설명합니다. 보고서 API는 서버 보고 기능을 확장합니다. 서버 API는 플랫폼 운영자가 거래 서버 및 이력 서버 기능을 추가할 수 있도록 합니다.

그들의 이름은 자명해 보일 수 있지만, 범위와 가용성은 중개인의 라이센스 및 기술 문서에서 확인해야 합니다.

MQL5

MQL5는 MetaTrader 5 내에서 사용되는 언어 및 프로그래밍 환경입니다. 트레이더와 개발자는 터미널에서 실행되는 전문가 고문, 지표, 스크립트 및 서비스를 구축합니다.

MT5 내에서 차트 데이터, 지표 및 거래 기능이 필요한 자동화 전략을 위한 기본 경로입니다. 이는 브로커-유동성 제공자 프로토콜이 아닙니다.

메타트레이더 5 파이썬 통합

공식 MetaTrader5 Python 패키지는 Python 프로그램이 데이터를 읽고 MetaTrader 5 터미널을 통해 거래 요청을 보낼 수 있도록 해줍니다. 중요한 단어는 터미널을 통해입니다.

공식 파이썬 문서에 따르면, 이 패키지는 프로세스 간 통신을 사용하여 터미널과 직접 통신합니다. 이는 임의의 클라우드 서비스가 브로커의 MT5 서버에 직접 연결되는 것을 허용하지 않습니다.

그 구별은 배포를 변화시킵니다. 파이썬 전략은 호환 가능한 터미널 환경, 계정 세션, 모니터링 및 터미널 재시작에 대한 계획이 필요합니다. pip install MetaTrader5가 서버 측 브로커 API를 생성하는 것처럼 설계되어서는 안 됩니다.

하나의 주문은 여러 API를 통과할 수 있습니다

한 트레이더가 브로커의 모바일 앱에서 100,000 유닛의 EUR/USD를 구매한다고 가정해 보겠습니다.

1. 앱은 REST를 통해 계정, 기호 사양 및 권한을 로드합니다.
2. 현재 입찰과 요청을 WebSocket을 통해 수신합니다.
3. 거래자가 구매를 탭합니다. 앱은 고유한 클라이언트 주문 ID와 함께 주문 명령을 전송합니다.
4. 중개인의 위험 서비스는 마진, 한도 및 시장 상태를 확인합니다.
5. 거래 플랫폼은 주문을 수락하거나 거부합니다. 해당 플랫폼은 MT5일 수 있습니다.
6. 브로커의 실행 모델에 따라 외부 노출이 FIX, 게이트웨이 또는 다른 커넥터를 통해 유동성 공급자에게 전송될 수 있습니다.
7. 실행 보고서는 스택을 통해 반환됩니다.
8. 앱은 이벤트 스트림을 통해 업데이트된 주문, 위치 및 잔액을 수신합니다.

REST는 이 순서에서 FIX와 경쟁하지 않았습니다. 그들은 서로 다른 경계에서 작업했습니다.

약한 API를 드러내는 타임아웃 사례

주문 API의 어려운 부분은 요청을 보내는 것이 아니라, 응답이 사라졌을 때 무슨 일이 발생했는지를 아는 것입니다.

앱이 이 지시를 보낸다고 가정해 보세요:

유로/달러 매수, clientOrderId = mobile-84721

요청 시간이 초과되었습니다. 두 가지 가능성이 있습니다:

• 중개인은 그것을 결코 받지 못했습니다;
• 브로커가 이를 수락했지만, 응답이 앱에 도달하지 않았습니다.

무작정 같은 거래를 다시 보내는 것은 두 개의 포지션을 만들 수 있습니다.

더 안전한 작업 흐름은:

1. 같은 클라이언트 주문 ID를 유지하십시오.
2. 권위 있는 주문 상태를 조회하거나 주문 이벤트를 기다리십시오.
3. 서버가 동일한 ID를 가진 반복된 명령을 거부하거나 중복 제거하도록 하십시오.
4. 최종 주문을 조정하고 다른 재시도를 활성화하기 전에 기록을 작성하십시오.

이것이 제가 헤드라인 요청 비율에 대해 묻기 전에 API 공급업체에게 멱등성에 대해 묻는 이유입니다. 타임아웃 후에 금융 행동을 중복할 수 있는 빠른 엔드포인트는 좋은 거래 엔드포인트가 아닙니다.

사용 사례에 따른 REST vs WebSocket vs FIX vs MT5

요구 사항	먼저 검토할 인터페이스	이유
계좌 내역을 보여주는 브로커 웹사이트	REST	간단한 쿼리, 익숙한 인증 및 명확한 응답
웹 또는 모바일 앱의 실시간 감시 목록	WebSocket	지속적인 폴링 없이 이벤트로 도착하는 견적
맞춤형 앱에서의 소매 주문 입력	REST 명령 및 WebSocket 상태	실시간 확인 및 체결 업데이트가 포함된 명확한 제출 흐름
브로커와 유동성 공급자 간의 연결	FIX 또는 공급자의 인증된 커넥터	거래 시스템 간의 표준 주문 및 실행 워크플로우
MT5 주변의 브로커 관리	MT5 매니저 API	플랫폼 측 관리 유틸리티를 위해 구축됨
장소에 대한 맞춤형 MT5 연결	MT5 게이트웨이 API 또는 테스트된 브리지/게이트웨이 설정	플랫폼 시장 연결성을 위해 설계됨
MT5에서 실행되는 전문가 어드바이저	MQL5	네이티브 터미널 자동화 및 테스트 환경
MT5 터미널을 통한 파이썬 분석 및 실행	MetaTrader 5 파이썬 패키지	파이썬에 터미널 데이터 및 거래 기능 접근 제공
역사적 연구 데이터셋	REST 또는 대량 데이터 내보내기	더 쉬운 페이지 매김, 날짜 범위 및 반복 가능한 검색

이 표는 출발점입니다. 최종 선택은 제공자의 실제 API, 속도 제한, 인증, 지원되는 주문 유형 및 서비스 보장에 따라 달라집니다.

외환 거래 API를 선택하기 전에 제가 묻는 질문들

시장 데이터

• 피드는 틱별, 통합 또는 샘플링됩니까?
• 입찰 및 요청 타임스탬프는 출처에서 생성되나요, 아니면 배송 시 생성되나요?
• 스트림에 시퀀스 번호가 포함되어 있습니까?
• 클라이언트가 연결 끊김 후 데이터를 어떻게 복구합니까?
• 계약 설정이 변경될 때 기호 사양이 버전 관리됩니까?

주문

• 고유한 클라이언트 주문 ID가 있나요?
• 생성 및 취소 명령은 아이템포턴트입니까?
• API가 부분 체결 및 여러 실행 보고서를 보고할 수 있나요?
• 타임아웃 후 어떤 기록이 권위 있습니까?
• 거부된, 만료된 및 교체된 주문은 어떻게 표시됩니까?

운영

• 요청, 구독 및 연결 한도는 무엇인가요?
• 데모 환경과 라이브 환경은 행동적으로 동등한가요?
• 상태 페이지와 예정된 유지보수 공지가 있나요?
• 클라이언트, 브로커 및 거래소 간에 로그를 상관시킬 수 있나요?
• 브레이킹 변경 사항은 어떻게 버전 관리되고 발표되나요?

보안

• 어떤 권한이 애플리케이션 또는 토큰별로 제한될 수 있나요?
• 자격 증명은 어떻게 회전되고 취소됩니까?
• IP 허용 목록, TLS 및 별도의 프로덕션 자격 증명이 지원되나요?
• 하나의 서비스가 거래 허가를 받지 않고 데이터를 읽을 수 있나요?
• 모든 특권 행동이 감사 로그에 기록되나요?

답변은 API의 레이블보다 더 많은 정보를 제공합니다. 두 개의 REST API는 REST와 WebSocket보다 실제 품질에서 더 다를 수 있습니다.

통합 전에 브로커가 결정해야 할 사항

API 프로젝트는 소유권이 모호할 때 보통 어려워집니다.

개발이 시작되기 전에 이러한 포인트를 정의하십시오:

1. 기록 시스템. 어떤 시스템이 주문, 충전, 잔고 및 포지션을 소유하고 있습니까?
2. 이벤트 순서. 중복, 지연 메시지 및 순서가 잘못된 업데이트는 어떻게 처리됩니까?
3. 복구. 재연결 후 어떤 스냅샷이 로드되며, 이벤트는 어떤 커서에서 재개되나요?
4. 위험 경계. 주문이 플랫폼이나 장소에 도달하기 전에 어떤 확인이 이루어지나요?
5. 기호 모델. 누가 이름, 계약 크기, 세션 및 가격 정밀도를 매핑합니까?
6. 감사 추적. 앱에서 최종 실행 보고서까지 클라이언트의 하나의 행동을 추적할 수 있나요?

여기에서 플랫폼 결정이 운영 결정으로 전환됩니다. Quadcode의 중개 인프라는 거래 플랫폼, 클라이언트 애플리케이션, CRM, 백 오피스, 리스크 및 통합을 하나의 환경으로 통합합니다. 필요한 REST, 스트리밍, MT5 또는 유동성 연결은 여전히 솔루션 설계에 작성되어야 하며 중개인의 자체 주문 흐름에 대해 테스트되어야 합니다.

최종 답변

명확한 요청, 스냅샷 및 기록을 위해 REST를 사용하십시오. 애플리케이션이 실시간 변경 사항을 수신해야 할 때는 WebSocket을 사용하십시오. 전문 시스템 간의 표준화된 거래 통신을 위해 FIX를 사용하십시오. MetaTrader 5가 플랫폼의 일부일 때는 관련 MT5 인터페이스를 사용하십시오.

대부분의 외환 제품은 조합이 필요합니다. 네트워크 실패 후, 견고한 아키텍처는 세 가지 질문에 대답할 수 있습니다: 주문이 접수되었나요? 실행되었나요? 연결된 모든 시스템이 이제 결과에 동의하나요?