API REST / STREAM

Spoiler:

On parle de l'API IG Markets, il n'est pas bien dans le forum IG Markets ?

Spoiler:

pas faux, je crois que nos deux points de vue se défendent Hyde

Spoiler:

Je suis d'accord pour dire que nous sommes tombés d'accord.

Bonjour,

J'ai l'impression que depuis quelques jours la connexion avec l'API ne provoque plus la déconnexion de l'interface web.

Bonne nouvelle, mais il faudrait confirmer ça dans le temps et avec des comptes différents.
Je fais des tests uniquement en mode démo (trop peur de lancer un vrai ordre sans faire exprès en bidouillant).

Bonsoir,

J'utilise l'interface Web en plus des API depuis quelques jours et les deux fonctionnent bien ensemble lorsqu'on ouvre d'abord la version API puis la version Web.

En début de semaine dans l'autre sens cela déconnectait de la version Web.

Bonjour à tous,
J'envisage de développer un programme en .NET afin de détecter les opportunités de mon système de trading en multi-ut (X ticks).
Mais avant de me lancer, je me pose une question sur le quota de récupération d'historique de cours, selon le site ig :
Historical price data points per week: 10,000

Si on considère qu'un tick = 1 data point, je ne vais pas aller loin avec 10000 ticks.

Comment comprenez-vous cette limite ? que représente un data point ?

Merci de votre aide

Bon je viens de voir que les 10000 data points ne s'appliquaient qu'au REST seulement. Pas de restriction sur du streaming visiblement.
Le mieux, c'est que je teste mais je veux bien votre sentiment quand même

Bonjour,
C'est une limitation glissante sur une semaine de 10 000 résultats de recherche de leurs API REST "/deal/prices/".

Par exemple, tu recherches le prix journalier du DAX30 entre le 01 février 2015 00h et le 2 février 2015 00h, tu dois avoir, puisque c'est journalier, 1 résultat unique :
https://api.ig.com/gateway/deal/prices/IX.D.DAX.IDF.IP/DAY/2015-02-01%2000%3A00%3A00/2015-02-02%2000%3A00%3A00

Ton totalallowance est de 10000 et reste à 10000. Mais ton remainingAllowance passe à 9999 :

Code : #

    "allowance": {
        "remainingAllowance": 9999,
        "totalAllowance": 10000,
        "allowanceExpiry": 604714
}

L'allowanceExpiry est de 604 714 soit environ 168h = 6,999 jours.

DataPoint est le terme générique car on peut récupérer des valeurs pour des horizons de temps différents (journalier, horaire ou 5min).

Oui heureusement que via leur serveur lightstreamer on est pas limité à 10 000 ticks

ok cool. Merci melmoth

Je viens de faire mumuse avec les companions REST et STREAM et l'appli de maroxe.

les doc de référence chez ig ont un train de retard entre ce qu'elle renvoi réellement et ce qui est écrits ...

Entre autre je trouve qu'il manque un schéma sur l'interfonctionnement entre les deux API.

Typiquement , et merci maroxe :
1) REST : Connexion aux serveur d'ig pour récuperer des Token et le endpoint LS
2) STREAM : Ouverture de la connexion aux serveur LS
A partir de ce point on peut utiliser la totalité des API REST & STREAM

SI j'ouvre (ou ferme c'est pareil) une position
1) je lance le POST /position/otc en REST
j'ai en réponse un dealReference
2) en même temps et si j'ai fait une souscription sur le stream TRADE CONFIRMS (ou OPU) je reçois un message.
Donc à moi de matcher le dealReference venant du REST avec le dealReference venant du STREAM ...

Autre truc quand on ferme un ticket le message dans CONFIRMS peut trsè bien affecté un ou plusieurs dealID si je suis en position forcé à Faux et que je ferme plus que la valeur facial d'un ticket (exempele de deux ticket avec 1,2 et 2,3 lots, si je demande un ticket dans l'autre sens de 2 lots, ig va me fermer le 1,2 +0,8 du 2,3 (si ils ont été ouvert dans cette ordre)).

---

Est-ce que quelqu'un s'est amusé à dessiner une machine à état des deal ? (y'a rien dans la doc à ce sujet).

Je dirais qu'il y a deux chemins possible
OPEN ----> FULLYCLOSED
ou
OPEN ----> PARTIALLYCLOSED ----> FULLYCLOSED

En voyez-vous d'autres ?

Je suis d'accord, ils n'ont pas fait de schéma d'architecture pour donner une big picture de leur APIs. C'est bien dommage mais bon c'est pas le plus important : ils proposent une API .

Oui il faut faire une jointure sur :
- côté REST : le dealReference de l'item retourné sur le POST
- Côté STREAM : le dealReference du champ OPU de l'item trade

C'est du CRUD l'API REST. Par conception, il est normal qu'il n'expose pas de machine à états, c'est du pur Web, on n'accède qu'à des ressources. Mais cela me semble bien compliqué une state machine pour ce cas : on a une position qui a cinq états possibles et le ticket courant (le deal) deux : accepté et refusé. Ca suffit

Ok, c'est quoi CRUD ?

Dans OPU tu n'as pas le dealReference, uniquement dans CONFIRMS (testé à l'instant).

Tu as listé quoi comme état possible ?

Pourtoi quel est la différence entre OPU et WOU ? j'avoue que je ne pige pas bien la différence.

CRUD = Create Read Update Delete. Cela correspond aux méthodes HTTP des messages (put, GET, POST, DELETE).
OPU : les positions ouvertes : tu es dans le marché
WOU : les positions non ouvertes (qui "travaillent") en attente d'exécution

Est-ce que pour ceux qui ont fait des programme d'interfaçage avec l'API vous vous êtes amusez à relever le temps entre "je clique sur mon bouton Buy/Sell" et l'ordre est servi ?

Je fais des mesures dans mon code, mais le temps de calcul local est théoriquement négligeable par rapport à la latence réseau.

Mon constat serait plutôt que l'interface web (Sous FF) est un poil plus lente ...
Ca peut aussi venir du fait que dans le prog de maroxe que je bidouille il n'y a pas de fenêtre de confirmation du deal
Donc tu peux immediatement inverse la position ou la clôturer.

---

En parallèle je m'interroge sur la rapidité/lenteur d'excel face à des programmes écrit dans des langages plus "rapide"

Excellent :
J'ouvre un lot
Je ferme partiellement un lot avec _method:DELETE
et bien quelque soit la direction "BUY|SELL" passé en argument, l'API n'en a rien à faire et n'en tiens pas compte et ferme bien la quantité demandé.
Les deux seuls arguments "important" et "mandatory"sont dealId et size de toute façon ...

A quoi ça sert de passer l'argument direction dans ce cas là ?

En effet cela ne sert à rien de fournir la direction. C'est même heureux qu'il n'en tienne pas compte.

Yes mais elle est obligatoire dans la requête sinon la demande n'est pas exécuté.

C'est excellent le mdoe Stream, car si je lance une action via l'iphone, le flux stream envoi des message d'ouverture/fermeture de ticket.

Par exemple on pourrait imaginer, : j'ouvre ou je ferme mes deals "normalement" avec les interfaces classique à disposition (web, prt, iphone).
A côté et en // je lance mon programme qui va aller chercher mes positions ouverte et va appliquer des stratégies de SL à 0 ou de coupure de ticket sans que je m'en occupe ...

Y'a des trucs sympa à faire.

Oui c'est exactement ce que je travaille de mon côté aussi. On peut personnaliser beaucoup de choses pour se faciliter la vie. Ca c'est super.

Par contre il faut faire attention à la déconnexion. On peut se déconnecter via le code, par la-même être déconnecter automatiquement de l'interface Web et pourtant rester connecté sur prt (j'ai fait le test en PROD).