Frage

Ich möchte damit beginnen, unsere Anwendungsgeschäftsschichten in eine Sammlung von REST-Webdiensten zu verschieben.Der Großteil unseres Intranets wurde jedoch mit Classic ASP erstellt und die meisten Entwickler, bei denen ich arbeite, programmieren weiterhin in Classic ASP.Damit sie von den Vorteilen eines einzigartigen Satzes von Web-APIs profitieren können, müsste dieser im Idealfall über klassische ASP-Seiten aufgerufen werden.

Ich habe nicht die geringste Ahnung, wie das geht.

War es hilfreich?

Lösung

Sie können eine Kombination aus JQuery und JSON-Aufrufen verwenden, um REST-Dienste vom Client zu nutzen

oder

Wenn Sie mit den REST-Diensten der ASP-Ebene interagieren müssen, können Sie diese verwenden

MSXML2.ServerXMLHTTP

wie:

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

Andere Tipps

@KP

Sollte man eigentlich nutzen MSXML2.ServerXMLHTTP von ASP/serverseitigen Anwendungen. XMLHTTP sollte nur clientseitig verwendet werden, da WinInet verwendet wird, das für die Verwendung in Server-/Dienst-Apps nicht unterstützt wird.

Sehen http://support.microsoft.com/kb/290761, Fragen 3, 4 und 5 und

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

Dies ist sehr wichtig, da sonst Ihre Web-App hängen bleibt und allerlei seltsamer Unsinn passiert.

Hier sind einige Artikel, die beschreiben, wie man einen Webdienst von einer Klassen-ASP-Seite aus aufruft:

Einige der hier präsentierten Antworten scheinen abzudecken, wie ClassicASP zur Nutzung von Webdiensten und REST-Aufrufen verwendet werden kann.

Meiner Meinung nach könnte eine aufgeräumtere Lösung darin bestehen, dass Ihr ClassicASP Daten nur in REST-Formaten bereitstellt.Überlassen Sie das „Mashup“ nach Möglichkeit Ihrem browserbasierten Clientcode.Sie sollten dies tun können, ohne andere ASP-Komponenten einzubinden.

So würde ich eine glänzende neue REST-Unterstützung in ClassicASP modellieren:

  1. Stellen Sie eine einzelne ASP-Webseite bereit, die als Landeplatz fungiert
  2. Der Landeplatz verarbeitet zwei Parameter:Verb und URL sowie eine Reihe von Formularinhalten
  3. Verwenden Sie eine Art Schalterblock, überprüfen Sie die URL und leiten Sie das Verb (und den Formularinhalt) an einen relevanten Handler weiter
  4. Der Handler verarbeitet dann das Verb (PUT/POST/GET/DELETE) zusammen mit dem Formularinhalt und gibt einen Erfolgs-/Fehlercode sowie entsprechende Daten zurück.
  5. Ihr Landing Pad prüft den Erfolgs-/Fehlercode und gibt den jeweiligen HTTP-Status sowie alle zurückgegebenen Daten zurück

Sie würden von einer Support-Klasse profitieren, die die Formulardaten von/nach JSON dekodiert/kodiert, da dies Ihre clientseitige Implementierung vereinfacht (und möglicherweise die Menge der übergebenen Daten rationalisiert).Sehen Sie sich das Gespräch hier an Gibt es gute Bibliotheken zum Parsen von JSON in Classic ASP?

Stellen Sie abschließend auf der Clientseite eine Methode bereit, die ein Verb, eine URL und Datennutzdaten akzeptiert.Kurzfristig erfasst die Methode die Parameter und leitet sie an Ihren Landeplatz weiter.Längerfristig (sobald Sie von Classic ASP wechseln) kann Ihre Methode die Daten an die „echte“ URL senden.

Viel Glück...

Eine andere mögliche Lösung besteht darin, eine .NET-DLL zu schreiben, die die Aufrufe durchführt und die Ergebnisse zurückgibt (vielleicht etwas wie RESTSharp umschließen – geben Sie ihm eine einfache API, die an Ihre Bedürfnisse angepasst ist).Anschließend registrieren Sie die DLL als COM-DLL und verwenden sie über die CreateObject-Methode in Ihrem ASP-Code.

Ich habe dies für Dinge wie das Erstellen signierter JWTs und das Salting und Hashing von Passwörtern getan.Es funktioniert gut (während Sie wie verrückt daran arbeiten, das ASP neu zu schreiben).

Sie benötigen lediglich einen HTTP-Client.In .Net funktioniert WebRequest gut.Für klassisches ASP benötigen Sie eine bestimmte Komponente wie Dieses hier.

Eine andere Möglichkeit besteht darin, das WinHttp-COM-Objekt zu verwenden Verwenden des WinHttpRequest COM-Objekts.

WinHttp wurde für die Verwendung mit Servercode entwickelt.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top