Suivi évolutions des API sur IGLabs

Il était temps

@- : Merci à toi, cette file est d'une grande aide.

Merci pour l'info, ce langage ruby parrais plus simple, cela me fait penser il y un truc qui manque a la L3 ou a Takascalper, des boutons d'ordre programmes d'avance (taille et sl ).

Cela permet de piramider rapidement sur une entrer trop tôt par exemple, sens a avoir a calculé la taille et le sl du prochain ordre.

Je verrais bien une zapette pop hop avec 3 ou 4 bouton bye et sell plus un closs all et closs profit.

Le top serait que la taille des lots et du stop soit calculer au pourcentage de l'équité.

Si cela peu faire avancer le Schmilblick, je tradais de cette façon en micro mt4 ce serrait bien mieux en api bien que la taille des lots peux posé problème.

Ruby = un sacré mélange entre du Perl (beaucoup) et du python. C'est un langage interprète.

Il a été créé il y a quelque années(10 ?).

Ça ma fait tilt le code bin j'avais installé des scripts en cgi sur un de mes site il y a bien longtemps, mes connaissances ne vont pas plus loin.

yo !

Apparement le bug pour supprimer une position a été corrigé, vous confirmez ?
Je suis en train de tester avec la method delete et sans modifier les headers mais j'ai une erreur inconnue:

Code : #

javax.validation.constraints.NotNull

ça marche pour vous ?

Heu les WO sont dispo depuis le début ?
Par contre c'était uniquement une distance en point pas un niveau ...

J'aimerai bien qu'ils complètent le message wou avec le "good-till-date"

---

Merci pour la News j'irai voir ce qu'ils ont modifié

Je n'ai pas fait de tests précis, mais je peux te dire (de mémoire) que :
- Il y a un délai minimal à respecter pour lancer deux ordres de suite (je ne le connais pas)
- Un ordre parti du PC est considéré comme actif après un délai qui est variable : il faut attendre un CONFIRM ou un OPU pour être sûr de sa validation

je confirme le premier point. ig se protège des ordres en mode mitraillete. De mémoire ça tourner dans les 100/500ms entre chaque ordre.
Idem pour le deuxième point. en générale l'OPU/CONFIRMS arrive dans les 100ms après que tu ai balancer ton ordre via le REST.

Oui tu peux balancer plusieurs ordre sur le même niveau, tout en respectant le délais entre chaque ordre)

Délais d'annulation ou de cloture d'un ordre : même processus.
D'expèrience, la cloture est toujours un poil plus long (si open ou WOU est dans les 100ms, le delete va être de l'ordre "moyen" de 150ms).

J'ai plus la valeur exact c'est peut-être même moins que 100ms.

Quand tu envoi trop tôt of génère un message d'erreur : duplicate order. Regarde dans le forum j'en avais parlé. J'avais peut être donné la valeur mesuré ... ou pas

Merci pour l'info -

qu'est ce qui explique que c'est plus long que sans api ?

perso j'avais pu améliorer le transfert d'ordre en maintenant ouvert la session HTTPS. c'est ça qui te bouffe 100ms à chaque passage d'ordre.

Une fois la session HTTPS "améliorer" tu tombes bien sur les 100ms annoncés par ig.

Dits autrement : Faut pas utiliser les exemples fourni apr ig, il ne sont pas performant, c'est un démonstrateur.

En plus envoyer un ordre c'est pas sorcier, c'est une simple requête HTTPS donc accessible à tout programmeur.

Merci !

Merci une fois de plus !

Pour y arriver, j'ai du recourir à une astuce en passant un ordre de sens contraire sur le nombre de positions ouvertes.

Si je suis en hedging avec des positions BUY et SELL simultanées, je dois bien sûr passer deux ordres.

Sinon, il y a ce post de falex :
api-rest-t5881-120.html?hilit=delete#p273296
qui renvoie ici :
https://labs.ig.com/node/233

Autre post complémentaire de Falex :
utilisation-des-api-ig-avec-c-t9046.htm ... te#p255992

La seule fonction que j'ai pu trouver (pour le moment) sur internet supprime les WOU les uns après les autres :

Code : #

// Delete all existing working orders
function deleteAllOrders() {
	return new Promise((res, rej) => {
		let response = [];
		let tickets = [];
		let index = 0;
		let close = {};
		get('/workingorders')
			.then(r => {
				let temp = r.body.workingOrders;
				if (temp.length === 0)(res('There is no order to close'));
				for (let i = 0; i < temp.length; i++) {
					tickets.push(temp[i].workingOrderData.dealId);
				}

				function _close(index) {
					if (tickets[index]) {
						del('/workingorders/otc/' + tickets[index], close)
							.then(r => {
								get('/confirms/' + r.body.dealReference)
									.then(r => {
										if (r.status !== 200) {
											rej(r);
										} else {
											index++;
											_close(index);
											response.push(r.body);
										}
									})
									.catch(e => {
										rej(e);
									});
							})
							.catch(e => {
								rej(e);
							});
					} else {
						res(response);
					}
				}
				_close(index);

			});
	});
}

https://github.com/gfiocco/node-ig-api

Peut être si tu passes un ordre par téléphone avec un Gars du desk ?

Tu as vus le site web labs.ig.com qui a été fermé/maintenance pendant presque toute la semaine.

Soit c'étiat une simple migration de serveur web
Soit c'était plus profond

En tout je m'intéroge sur la pérénité des API public.
Dans le forum y'a presque rien.
Côté nouveauté rien
Côté bug les ordre WOU se sont transformé en OPU pendant quelques temps.

Donc va falloir suivre de très près la trajectoire que va donner ig a son API grand public.

Pour avoir papoter avec des copains qui ont bosser sur le FIX ... c'est une vrai m3rde. Les API en REST sont beaucoup plus propre et surtout sont plus dans l'air du temps.

Avec le FIX tu fais un bon en arrière de 15/20 ans ... mais bon c'est ainsi que fonctionne les grosses boites de la finance avec leur brocker.

Je te rejoints : ça m'etonnerai qu'ils les coupent demain, mais à moyen terme faudra voir à peut-être s'adapter.
Tu verras au moment voulu.