Question

J'aimerais commencer à déplacer nos couches métier d'application vers une collection de services Web REST.Cependant, la plupart de notre Intranet a été construit en utilisant Classic ASP et la plupart des développeurs avec lesquels je travaille continuent de programmer en Classic ASP.Idéalement, pour qu’ils puissent bénéficier des avantages d’un ensemble unique d’API Web, il faudrait qu’il soit appelé depuis les pages ASP classiques.

Je n'ai pas la moindre idée de comment faire ça.

Était-ce utile?

La solution

Vous pouvez utiliser une combinaison d'appels JQuery et JSON pour consommer les services REST du client.

ou

si vous devez interagir avec les services REST de la couche ASP, vous pouvez utiliser

MSXML2.ServerXMLHTTP

comme:

Set HttpReq = Server.CreateObject("MSXML2.ServerXMLHTTP")
HttpReq.open "GET", "Rest_URI", False
HttpReq.send

Autres conseils

@KP

Vous devriez en fait utiliser MSXML2.ServerXMLHTTP à partir d’applications côté ASP/serveur. XMLHTTP ne doit être utilisé que côté client car il utilise WinInet qui n'est pas pris en charge pour une utilisation dans les applications serveur/service.

Voir http://support.microsoft.com/kb/290761, questions 3, 4 et 5 et

http://support.microsoft.com/kb/238425/.

C'est très important, sinon votre application Web se bloquera et toutes sortes d'absurdités étranges se produiront.

Un certain nombre de réponses présentées ici semblent expliquer comment ClassicASP peut être utilisé pour consommer des services Web et des appels REST.

À mon avis, une solution plus simple pourrait être que votre ClassicASP serve uniquement les données aux formats REST.Laissez le code client basé sur votre navigateur gérer le « mashup » si possible.Vous devriez pouvoir le faire sans incorporer d’autres composants ASP.

Voici donc comment je créerais le nouveau support REST dans ClassicASP :

  1. fournir une seule page Web ASP qui fait office de plate-forme d'atterrissage
  2. La piste d'atterrissage gérera deux paramètres :verbe et URL, plus un ensemble de contenus de formulaire
  3. Utilisez une sorte de bloc de commutation, inspectez l'URL et dirigez le verbe (et le contenu du formulaire) vers un gestionnaire approprié
  4. Le gestionnaire traitera ensuite le verbe (PUT/POST/GET/DELETE) avec le contenu du formulaire, renvoyant un code de réussite/échec ainsi que des données, le cas échéant.
  5. Votre plate-forme d'atterrissage inspectera le code de réussite/échec et renverra le statut HTTP respectif ainsi que toutes les données renvoyées.

Vous bénéficieriez d'une classe de support qui décode/encode les données du formulaire depuis/vers JSON, car cela facilitera votre implémentation côté client (et rationalisera potentiellement le volume de données transmis).Voir la conversation ici à Existe-t-il de bonnes bibliothèques pour analyser JSON dans Classic ASP ?

Enfin, côté client, fournissez une méthode qui prend une charge utile de verbe, d'URL et de données.À court terme, la méthode rassemblera les paramètres et les transmettra à votre plate-forme d'atterrissage.À plus long terme (une fois que vous quittez Classic ASP), votre méthode peut envoyer les données à la « vraie » URL.

Bonne chance...

Une autre solution possible consiste à écrire une DLL .NET qui effectue les appels et renvoie les résultats (peut-être encapsuler quelque chose comme RESTSharp - donnez-lui une API simple personnalisée selon vos besoins).Ensuite, vous enregistrez la DLL en tant que DLL COM et l'utilisez dans votre code ASP via la méthode CreateObject.

J'ai fait cela pour des choses comme la création de JWT signés et le salage et le hachage de mots de passe.Cela fonctionne bien (pendant que vous travaillez comme un fou pour réécrire l'ASP).

Tout ce dont vous avez besoin est un client HTTP.Dans .Net, WebRequest fonctionne bien.Pour l'ASP classique, vous aurez besoin d'un composant spécifique comme celui-ci.

Une autre possibilité est d'utiliser l'objet COM WinHttp Utilisation de l'objet COM WinHttpRequest.

WinHttp a été conçu pour être utilisé à partir du code serveur.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top