IIS pour requêter sur API Swagger

**Pierre Fauconnier** · 13/08/2021, 14h35

Salut.

Afin de pouvoir requêter via une api Swagger, je dois installer IIS sur mon ordi (Windows 10). Je n'ai pas beaucoup de doc sur IIS lui-même de la part du prestataire Swagger, et je ne sais donc pas quoi installer ni comment.

IIS Express est-il suffisant? Si non, que dois-je installer? Certains d'entre vous ont-ils déjà installé IIS sur W10 et pourraient-ils me tuyauter sur des tutos ou autres?

D'avance, merci pour vos infos.

**Incorporated** · 18/08/2021, 15h01

Bonjour,

Il existe un outil intégré à Windows 10 qui permet d'exécuter IIS.

Voici un petit tutos d'explication pour l'installation :

https://blog.itgs-solutions.ch/windo...-web-dans-iis/

Je n'ai jamais utilisé IIS sur Windows 10 mais rien ne vous empêche de monter une machine virtuelle afin de tester.

En revanche, son utilisation à l'air assez proche d'un serveur IIS classique.

**Pierre Fauconnier** · 20/08/2021, 08h21

Merci pour ton message et pour le lien donné. Cela m'a bien aidé pour trouver comment ouvrir IIS et configurer le site.

J'ai en fait pu trouver le iis sur mon windows 10 et j'ai configuré selon les données techniques transmises par le fournisseur de données. Je n'arrive pas à me connecter au site via httprequest => "le délai imparti à l'opération est dépassé". N'ayant pas beaucoup d'aide de la part de ce prestataire, je suis bloqué à ce niveau. Pourtant, j'arrive à me connecter sur sa base de tests, mais il y a plus de sécurité pour les vraies données et il faut travailler au travers d'un proxy. Apparemment, c'est là que le bât blesse et je ne trouve pas de doc ou d'exemples pertinents à ce niveau, ni chez le prestataire ni sur le web...

C'est donc un peu "rame, rame, rameurs, ramez, on n'avance à rien dans c'canoé"

**Incorporated** · 20/08/2021, 09h08

Et bien, si je ne m'abuse, l'utilisation de IIS permet d'héberger son site Web.

Donc techniquement, vous devriez pouvoir accéder (depuis votre Windows 10) à votre site web (si vous n'avez pas configuré de port spécifique) en tapant http://localhost ou bien http://127.0.0.1

Mais dans votre message, une chose m'interpelle, vous parlez de passer à travers un Proxy, j'ai dû mal à cerner votre demande concernant la relation entre la création du site web sur votre Windows 10 et votre prestataire ?

Si vous créer un site web sur votre Windows 10, ce serait plutôt de faire se requêter par d'autres machines sur le site web présent sur votre Windows 10 non ?

Si vous pouviez m'éclairer sur votre besoin, sur le Qui se connecte Où, je pourrais vous donner plus d'informations.

**Pierre Fauconnier** · 20/08/2021, 09h26

Merci de t'accrocher au sujet.

J'avoue ne pas savoir moi-même pourquoi je dois utiliser un proxy et pourquoi ça passe par IIS.

Mise en contexte:

J'utilise Swagger pour interroger une base de données distante liée à un erp. L'API Swagger requiert une connexion au site Web et utilise un protocole de requêtes pour renvoyer un json, par exemple http://monsite.com:2100/api/v1/customers pour récupérer la liste des clients dans un json. Grâce à l'adresse Web et une clé, je sais atteindre la base de tests et requêter pour récupérer des données. Ca fonctionne très bien et je n'ai pas besoin de proxy ni de iis ni de quoi que soit d'autre, juste le couple adresse/clé. Il n'est donc pas question pour moi de créer un site web, mais simplement d'interroger une url avec une clé pour recevoir un json en retour.

Ce prestataire a vendu une solution erp à mon client et je dois maintenant interroger la base de données de mon client (autre url et autre clé) pour récupérer les données réelles de son exploitation et mettre en place les tableaux de bord dans Excel. C'est là que ça se corse. Avec l'URL de mon client et la clé qui va avec, je sais interroger le service lorsque je suis connecté via le réseau de mon client (chez lui, donc). Lorsque je souhaite interroger les données hors de son réseau, je dois utiliser un proxy (pour des mesures de sécurité qui me passent largement au dessus de la tête). Le prestataire m'a fourni ces infos pour y arriver, et j'ai donc configuré iis et le "site web" comme décrit dans la doc (du moins je le pense, mais comme ça ne fonctionne pas, il y a un problème quelque part). Je reçois le message "le délai imparti à l'opération est dépassé". Je précise que je récupère les données au travers de HTTPREQUEST en VBA et que sur la base de tests, cela fonctionne très bien.

Evidemment, le prestataire "s'en lave les mains" et ne m'aide pas au delà de la doc fournie, se défaussant en disant que la configuration du proxy ne le regarde pas et qu'il n'offre pas ce service aux clients.

Voilà où j'en suis, à deux doigts d'envoyer le client et le prestataire sur les roses, car ce n'est clairement pas mon "core business" de m'atteler à ce genre de trucs auxquels je ne pige que dalle

.

**Incorporated** · 20/08/2021, 09h39

Merci pour ses explications beaucoup plus claire afin de comprendre votre demande.

Dans un premier temps, si vous avez suivi la documentation d'installation à la lettre, je part du principe que celle-ci est correct.

La question que je me pose c'est, à partir de quel moment, vous devez utiliser ce serveur pour récupérer les requêtes ? Lorsque vous êtes en télétravail ? (si vous en faite) Lorsque vous êtes dans votre société et non chez votre client ?

Parce que là ce qui m'interpelle dans votre explication c'est, à quel moment vous avez une connexion réseau chez votre client ? via un VPN ? Une règle de routage ?

**Incorporated** · 20/08/2021, 09h45

Ha et je viens de voir qu'il y a une partie de réécriture URL, vous avez mis quoi comme configuration pour le serveur où réside Hermes Consult API ?

**Pierre Fauconnier** · 20/08/2021, 10h02

Lorsque je suis chez mon client et connecté à internet de chez lui via son réseau e nwifi, ça fonctionne sans soucis. Mais je dois pouvoir interroger ses données de chez moi et ç'est là que ça coince. La doc renseignée plus haut n'est utile que "hors réseau du client". Je dois préciser que l'adresse ip utilisée pour la connexion aux données est http://172.xx.xxx.x:2100 et que les données sont hébergées chez le prestataire.

Le problème vient peut-être d'une mauvaise configuration de httprequest, mais je ne trouve pas des masses de doc à ce sujet sur le web. Je précise que httprequest fonctionne bien avec la base de tests et avec la base de prod lorsque je suis chez le client. C'est uniquement lorsque je suis à distance que ça pose problème, sans doute à cause d'une mauvaise configuration du proxy et/ou de la réécriture d'url.

J'en suis là. Je suis actuellement en ligne avec le support de Syneton (le prestataire), mais c'est un langage de sourds, pour l'instant.

**Pierre Fauconnier** · 20/08/2021, 10h02

Envoyé par Incorporated

Ha et je viens de voir qu'il y a une partie de réécriture URL, vous avez mis quoi comme configuration pour le serveur où réside Hermes Consult API ?

Je ne comprends pas la question ^^

**Incorporated** · 20/08/2021, 10h16

D'accord je vois, donc en réécriture URL vous avez bien renseigné http://172.xx.xxx.x:2100 ?

Vous sûr que ce n'est pas Https ?

Est-ce que lorsque vous êtes hors du réseau du client, vous arrivez à ping l'adresse IP mentionnée ?

Qu'avez-vous mis également dans la partie Match URL => Modèle ?

**Pierre Fauconnier** · 20/08/2021, 10h17

L'adresse de connexion est http://xxx.xx.xxx.x:2100/api/v1/yyy où les x sont bien entendu remplacés par l'adresse ip et les yyy constituent la requête proprement dite, en GET (Customers, Invoices, ...)

Au niveau du pattern de l'url, la doc renseigne consultapi/(.*). J'ai modifié en api/(.*) pour correspondre à l'adresse, et dans les propriétés de l'action, j'ai placé http://172.31.180.4:2100/api/v1/{R:1} comme renseigné dans la doc pour remplacer je suppose (.*) par tout ce qui suit l'url... (sur base de mes connaissances en regexp)...

Au début de mes tests, j'avais comme réponse "adresse incorrecte" ou quelque chose comme ça, puis actuellement, j'ai le problème de délai dépassé, ce qui me fait dire que j'ai avancé, mais pas assez...

**Incorporated** · 20/08/2021, 10h20

J'aurais plutôt renseigné ceci en modèle api/v1/customers/(.*) non ? ou bien api/v1/(.*)

**Pierre Fauconnier** · 20/08/2021, 10h27

Oui, ce n'est pas https. Chez mon client, ça fonctionne sans proxy et en http sur l'adresse http://172.xx.xxx.x:2100

**Pierre Fauconnier** · 20/08/2021, 10h38

Envoyé par Incorporated

J'aurais plutôt renseigné ceci en modèle api/v1/customers/(.*) non ? ou bien api/v1/(.*)

Pour moi, non, car ce n'est pas toujours customers. customers, c'est la requête proprement dite. Sur base de la doc, on a donc la racine http://172.xx.xxx.x:2100/api/v1/ qui est fixe et customers qui est variable et qui peut être remplacé par n'importe quelle requête acceptée par Swagger. C'est pour cela que le modèle est api/(.*) ou (.*) sera remplacé par tout ce qui suit api/ dans l'adresse envoyée au serveur.

Pour api/v1/(.*), j'aurais plutôt réécrit cela ainsi aussi, mais ça ne change fondamentalement pas les choses, c'est juste que (.*) ne contient pas V1/, mais le test de réécriture fonctionne avec les deux modèles. Je pense que le problème n'est pas dans la réécriture de l'url mais en amont, au moment de la connexion, probablement dans la configuration du proxy.

**Incorporated** · 20/08/2021, 10h41

Je m'interroge sur le lien avec le {R:1}, cela signifie qu'il fait référence à la valeur arrière.

Vous pouvez avoir plus d'informations ici :

https://weblogs.asp.net/scottgu/tip-...rite-extension