Calling REST web services from a classic asp page

Question

I'd like to start moving our application business layers into a collection of REST web services. However, most of our Intranet has been built using Classic ASP and most of the developers where I work keep programming in Classic ASP. Ideally, then, for them to benefit from the advantages of a unique set of web APIs, it would have to be called from Classic ASP pages.

I haven't the slightest idea how to do that.

Answer 1

You could use a combination of JQuery with JSON calls to consume REST services from the client

or

if you need to interact with the REST services from the ASP layer you can use

MSXML2.ServerXMLHTTP

like:

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

Answer 2

@KP

You should actually use MSXML2.ServerXMLHTTP from ASP/server side applications. XMLHTTP should only be used client side because it uses WinInet which is not supported for use in server/service apps.

See http://support.microsoft.com/kb/290761, questions 3, 4 & 5 and

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

This is quite important, otherwise you'll experience your web app hanging and all sorts of strange nonsense going on.

Answer 3

Here are a few articles describing how to call a web service from a class ASP page:

• Integrating ASP.NET XML Web Services with 'Classic' ASP Applications
• Consuming XML Web Services in Classic ASP
• Consuming a WSDL Webservice from ASP

Answer 4

A number of the answers presented here appear to cover how ClassicASP can be used to consume web-services & REST calls.

In my opinion a tidier solution may be for your ClassicASP to just serve data in REST formats. Let your browser-based client code handle the 'mashup' if possible. You should be able to do this without incorporating any other ASP components.

So, here's how I would mockup shiny new REST support in ClassicASP:

1. provide a single ASP web page that acts as a landing pad
2. The landing pad will handle two parameters: verb and URL, plus a set of form contents
3. Use some kind of switch block inspect the URL and direct the verb (and form contents) to a relevant handler
4. The handler will then process the verb (PUT/POST/GET/DELETE) together with the form contents, returning a success/failure code plus data as appropriate.
5. Your landing pad will inspect the success/failure code and return the respective HTTP status plus any returned data

You would benefit from a support class that decodes/encodes the form data from/to JSON, since that will ease your client-side implementation (and potentially streamline the volume of data passed). See the conversation here at Any good libraries for parsing JSON in Classic ASP?

Lastly, at the client-side, provide a method that takes a Verb, Url and data payload. In the short-term the method will collate the parameters and forward them to your landing pad. In the longer term (once you switch away from Classic ASP) your method can send the data to the 'real' url.

Good luck...

Answer 5

Another possible solution is to write a .NET DLL that makes the calls and returns the results (maybe wrap something like RESTSharp - give it a simple API customized to your needs). Then you register the DLL as a COM DLL and use it in your ASP code via the CreateObject method.

I've done this for things like creating signed JWTs and salting and hashing passwords. It works nicely (while you work like crazy to rewrite the ASP).

Answer 6

All you need is an HTTP client. In .Net, WebRequest works well. For classic ASP, you will need a specific component like this one.

Answer 7

Another possibility is to use the WinHttp COM object Using the WinHttpRequest COM Object.

WinHttp was designed to be used from server code.