2008-08-14 30 views
26

Me gustaría comenzar a mover nuestras capas de aplicaciones empresariales a una colección de servicios web REST. Sin embargo, la mayoría de nuestra Intranet se ha creado con ASP clásico y la mayoría de los desarrolladores en los que trabajo mantienen la programación en ASP clásico. Idealmente, entonces, para que se beneficien de las ventajas de un conjunto único de API web, debería llamarse desde páginas ASP clásicas.Llamar a servicios web REST desde una página asp clásica

No tengo la menor idea de cómo hacerlo.

Respuesta

25

Se puede usar una combinación de jQuery con llamadas JSON para consumir servicios REST desde el cliente

o

si tiene que interactuar con los servicios REST de la capa de ASP puede utilizar

MSXML2.ServerXMLHTTP

como:

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

¿Qué ocurre si mi servicio REST requiere autenticación básica? ¿Qué cambiaría eso en el segundo método de llamarlo desde ASP clásico? – mutex

0

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

9

@KP

En realidad debería utilizar MSXML2.ServerXMLHTTP de aplicaciones/lado del servidor ASP. XMLHTTP solo se debe usar en el lado del cliente porque usa WinInet que no es compatible con el uso en aplicaciones de servidor/servicio.

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

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

Esto es bastante importante, de lo contrario, experimentará la ejecución de su aplicación web y todo tipo de tonterías extrañas.

3

Algunas de las respuestas que se presentan aquí parecen cubrir cómo ClassicASP se puede usar para consumir servicios web & llamadas REST.

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

lo tanto, aquí es como me gustaría maqueta soporte de reposo de nuevo y brillante en ClassicASP:

  1. proporcionar una sola página web ASP que actúa como una pista de aterrizaje
  2. La pista de aterrizaje se encargará de dos parámetros: el verbo y el URL , además de un conjunto de contenidos de forma
  3. utilizan algún tipo de bloque de interruptores inspeccionar la URL y dirigir el verbo (y forman contenido) a un controlador relevante
  4. el manejador entonces procesará el verbo (PUT/POST/GET/Eliminar) junto con los contenidos del formulario, devolviendo un éxito/fracaso código más datos según corresponda.
  5. Su pista de aterrizaje inspeccionará el código de éxito/fracaso y devolver el estado HTTP correspondiente más cualquier regresado datos

que se beneficiaría de una clase de apoyo que decodifica/codifica los datos del formulario desde/a JSON, ya que facilitará su implementación en el lado del cliente (y posiblemente optimizará el volumen de datos pasados). Vea la conversación aquí en Any good libraries for parsing JSON in Classic ASP?

Por último, en el lado del cliente, proporcione un método que tome Verb, Url y carga útil de datos. A corto plazo, el método cotejará los parámetros y los enviará a su plataforma de aterrizaje. A más largo plazo (una vez que se aleja de ASP clásico), su método puede enviar los datos a la url "real".

Buena suerte ...

0

Otra posible solución es escribir un archivo DLL .NET que hace las llamadas y devuelve los resultados (tal vez algo así como envolver RESTSharp - darle una API simple medida de sus necesidades). Luego registra la DLL como una DLL COM y la usa en su código ASP a través del método CreateObject.

He hecho esto para cosas como la creación de JWT firmados y contraseñas hashing y salting. Funciona muy bien (mientras trabajas como un loco para reescribir el ASP).

Cuestiones relacionadas