Pregunta

Me gustaría comenzar a trasladar nuestras capas comerciales de aplicaciones a una colección de servicios web REST.Sin embargo, la mayor parte de nuestra Intranet se creó utilizando ASP clásico y la mayoría de los desarrolladores donde trabajo siguen programando en ASP clásico.Entonces, idealmente, para que se beneficien de las ventajas de un conjunto único de API web, tendrían que llamarlo desde páginas ASP clásicas.

No tengo la menor idea de cómo hacer eso.

¿Fue útil?

Solución

Podrías usar una combinación de JQuery con llamadas JSON para consumir servicios REST del cliente.

o

si necesita interactuar con los servicios REST desde la capa ASP puede utilizar

MSXML2.ServidorXMLHTTP

como:

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

Otros consejos

@kp

En realidad deberías usar MSXML2.ServerXMLHTTP desde aplicaciones ASP/del lado del servidor. XMLHTTP solo debe usarse en el lado del cliente porque usa WinInet, que no es compatible con aplicaciones de servidor/servicio.

Ver http://support.microsoft.com/kb/290761, preguntas 3, 4 y 5 y

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

Esto es bastante importante; de ​​lo contrario, su aplicación web se bloqueará y ocurrirán todo tipo de tonterías extrañas.

Aquí hay algunos artículos que describen cómo llamar a un servicio web desde una página ASP de clase:

Varias de las respuestas presentadas aquí parecen cubrir cómo se puede utilizar ClassicASP para consumir servicios web y llamadas REST.

En mi opinión, una solución más ordenada puede ser que su ClassicASP solo entregue datos en formatos REST.Deje que el código de su cliente basado en navegador maneje el 'mashup' si es posible.Debería poder hacer esto sin incorporar ningún otro componente ASP.

Entonces, así es como simularía el nuevo y brillante soporte REST en ClassicASP:

  1. Proporcionar una única página web ASP que actúa como plataforma de aterrizaje.
  2. La plataforma de aterrizaje manejará dos parámetros:verbo y URL, además de un conjunto de contenidos del formulario
  3. Utilice algún tipo de bloque de interruptor, inspeccione la URL y dirija el verbo (y el contenido del formulario) a un controlador relevante.
  4. Luego, el controlador procesará el verbo (PUT/POST/GET/DELETE) junto con el contenido del formulario, devolviendo un código de éxito/fracaso más datos según corresponda.
  5. Su plataforma de aterrizaje inspeccionará el código de éxito/error y devolverá el estado HTTP respectivo más cualquier dato devuelto.

Se beneficiaría de una clase de soporte que decodifica/codifica los datos del formulario desde/hacia JSON, ya que eso facilitará la implementación del lado del cliente (y potencialmente optimizará el volumen de datos pasados).Vea la conversación aquí en ¿Alguna buena biblioteca para analizar JSON en ASP clásico?

Por último, en el lado del cliente, proporcione un método que requiera una carga útil de verbo, URL y datos.A corto plazo, el método recopilará los parámetros y los enviará a su plataforma de aterrizaje.A largo plazo (una vez que abandone el ASP clásico), su método puede enviar los datos a la URL "real".

Buena suerte...

Otra posible solución es escribir una DLL .NET que realice las llamadas y devuelva los resultados (tal vez envuelva algo como RESTSharp; proporciónele una API simple personalizada según sus necesidades).Luego registra la DLL como DLL COM y la utiliza en su código ASP mediante el método CreateObject.

He hecho esto para cosas como crear JWT firmados y contraseñas saladas y hash.Funciona muy bien (mientras trabajas como loco para reescribir el ASP).

Todo lo que necesitas es un cliente HTTP.En .Net, WebRequest funciona bien.Para ASP clásico, necesitará un componente específico como Éste.

Otra posibilidad es utilizar el objeto COM WinHttp. Usando el objeto COM WinHttpRequest.

WinHttp fue diseñado para usarse desde el código del servidor.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top