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.
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
#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.
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
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:
provide a single ASP web page that acts as a landing pad
The landing pad will handle two parameters: verb and URL, plus a set of form contents
Use some kind of switch block inspect the URL and direct the verb (and form contents) to a relevant handler
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.
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...
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).
Another possibility is to use the WinHttp COM object Using the WinHttpRequest COM Object.
WinHttp was designed to be used from server code.
All you need is an HTTP client. In .Net, WebRequest works well. For classic ASP, you will need a specific component like this one.
Related
I am a bit confused about the difference between the two.
What I have been making till now is just deploying a web application that gets invoked by a URL and returns a response(json/XML) .
what I have read about rest web services
Its a way to communicate with web applications and to reveal your methods to the world.
Question 1
But in my case I did the same revealing the URL .
Platform independent
The rest features say that its Language-independent (C# can talk to Java)
Question 2
But in traditional approach also any language can invoke any web service by simple request (get/post) which ever implemented.
Question 3
What is rest and how to get started with it (specifically in terms of django) if possible.?
You are doing REST.
REST is not a library, or a format, it's simply a technique. What you call the "traditional approach" is exactly what REST is: simple requests via GET and POST (as well as PUT and DELETE) to an endpoint that returns JSON or XML.
That is in contrast to the previously-dominant way of making API requests, ie SOAP, which requires all sorts of up-front configuration of WSDL files and service discovery, along with particularly specified request formats.
I am trying to convert some of the SOAP based web services to Restful web services. In one of our existing SOAP based web service, we pass in a RequstDTO and the web service returns a ResponseDTO. The RequestDTO and ResponseDTO are both complex Java classes, which contain other custom JavaBean classes inside. It is a "READ" operation, so it naturally maps to the "GET" REST operation. Converting the ResponseDTO into XML or JSON has no issue. But I am not sure how to convert the RequestDTO into RESTful API.
The URL is going to be quite long, if I convert all the data in the RequestDTO into the query string. RESTful web service is usually consumed by application, thus the browser URL length limitation does not really apply. But a short URL is still preferred in most cases.
Some attributes in the RequestDTO might have PHI sensitive information and I prefer not to put them in the URL.
One solution is to embed the request data in the request body, even though it is a GET operation. But based on my research, such way is discouraged
http://tech.groups.yahoo.com/group/rest-discuss/message/9962
So what is the alternative? What is the right way to design this?
Im not exactly sure why you would need to pass the requestDTO to make the REST call.
Normally you just do something like this
GET /Resource/id
Now if the resource you want is like a secondary resource.. Example, you have a User and credit cards belonging to a user.
GET /User/{user_id}
GET /User/{user_id}/CreditCards/{credit_card_id}
And of course this can be nested however many times you want.
I am looking on advice on how best to approach a new project I need to develop. From the outset I must add, I have 0 experience with Web development on any level.
What I need to do is provide a web interface through the browser which will communicate with a server back end. The data retrieved will be sourced from either a DB or from another source - external device which the server itself will communicate with via IP. The data retrieved from the external device will always be a string format of n length (non unicode) and the DB data will mostly be strings and numbers with the odd blob thrown in (storing a picture). The communication will always go from the Client (web browser) to the Server. I don't believe that the server would need to instigate the comms.
I have Delphi XE, so started looking at using a REST server for communication and I think that seems to be OK. However, from what I can see, I need to create HTML web pages to "render" the data on the web browser. Is that true? Can I use the IW components with a REST server? If so, I'm not sure how to get the data to/from the browser UI. Am I better of investigating Ruby on Rails perhaps? From what I read on a different thread in here, it's based on MVC and some other areas which I feel, design wise, would fit how I would create the application (I was planning on creating the app based on the MVP or similar design pattern).
I think REST makes the most sense, so if the IW components can't be used, are there any 3rd party products I can use which would let me design "pretty" UI html. Given I don't know java script, would that be a stumbling block with REST too.
Thanks and hopefully I have provided enough information.
Thanks
Jason
Will a human being be responsible for typing the data retrieved from your external device into a web page?
If so, and you have no web development experience, Intraweb is definitely the way to go for Delphi programmers wanting to build a web application without learning new skills. For additional components to create a prettier UI I suggest using TMS Software's Intraweb Component Pack Pro.
If you don't need a human being to manually type in this data then you don't need Intraweb at all. Instead you would write a client application which presumably interrogated your external device for the data and then transmitted it to the REST server. Look at the documentation you've used to build your REST server and it should have a section on how to build a REST client.
You can build an ISAPI module with delphi that does the job, or include a HTTP server right into you executable with Indy, ICS or Synapse.
ISAPI will give you the freedom to choose Apache or IIS and give you all their power this way. Embeded HTTP server will give you a nice small application in which you control all ascpects of how it works.
Yes go with REST as it is simple and clean. All you need is to think and design the API (functions that your server will support). You can bind the APIs to the URL schema thus using the REST principle. I would do it simply like this.
A client makes a request. You show some form of GUI (load or render a HTML page with possible javascript)
User makes an action, you call appropriate API (or the user does it directly).
Show the user some result
Just guide the user process through a series of API calls until the result is made
You can use plain HTML and then add javascript if needed (jquery) or you can use ExtJS from Sencha which makes building a nice GUI a lot easier and is very well structured.
I would not use any "WYSIWYG" web tools. Plain old HTML written by your favorite editor is still the king in my opinion.
What would be the preferred method of pulling content from a remote database?
I don't think that I would want to pull directly from the database for a number of reasons.
(Such as easily being able to change where it is fetching the info from and a current lack of access from outside the server.)
I've been thinking of using HTTP as a proxy to the database basically just using some PHP to display raw text from the database and then grabbing the page and dumping it to a string for displaying.
I'm not exactly sure how I would go about doing that though. (Sockets?)
Right now I am building it around a blog/news type system. Though the content would expand in the future.
I've got a similar problem at the moment, and the approach I'm taking is to communicate from the client app with a database via a SOAP web service.
The beauty of this approach is that on the client side the networking involved consists of a standard HTTP request. Most platforms these days include an API to perform basic HTTP client functions. You'll then also need an XML or JSON parser to parse the returned SOAP data, but they're also readily available.
As a concrete example, a little about my particular project: It's an iPhone app communicating with an Oracle database. I use a web service to read data from the database and send the data to the app formatted in XML using SOAP. The app can use Apple's NSURLConnection API to perform the necessary HTTP request. The XML is then parsed using the NSXMLParser API.
While the above are pretty iPhone-specific (and are Objective-C based) I think the general message still applies - there's tools out there that will do most of the work for you. I can't think of an example of an HTTP API offhand, but for the XML parsing part of the equation there's Xerces, TinyXML, Expat...
HTH!
You might look at using AJAX (I recommend JSON instead of XML though). This is the technology underlying Google Maps.
What do you use as a test client for your stateful web services? Is it possible to use SoapUI? Are there best practices in this area?
You can do what's called a "Property Transfer" in SoapUI. For example, all our web services have to first call an authentication web service and obtain an authentication token.
I've set this up in SoapUI so that the returned auth token from the auth service is passed on to subsequent requests. It seems to work pretty well, but unless I'm missing a trick I wouldn't like to set it up for a lot of web services (i.e. you have to have an entry for each call you want to transfer data to / from).
Yeah, building SoapUI tests is slow, repetitive work. We didn't discover it until rewriting the SOAP server, and it makes great unit and system tests, but is s.l.o.w to create them.
Oh, and watch out for the memory leaks. Save very frequently. When you run out of memory, you can't save anymore. That sucks a little.
The property transfer stuff is awesome - you can have different scopes (test, request, global), and you can use GroovyScript to do dynamic stuff (like look up a particular date related to today's date, and so on).
With a properly formatted WSDL file, it will generate template requests for you, but you'll still need to tweak them a fair bit - or at least, I did.
I don't know whether it's practical to do this with SoapUI, but I've done things like this with both iTKO LISA and Parasoft SOATest. It wasn't for testing stateful web services, but simply executing multiple testing steps, storing results that are used in following steps. Both LISA and SOATest have the ability to define steps in the GUI that can store pieces of responses that are used in later requests.