I want to create a quick test web service for a demo. Is there a quick free way to just quickly and easily make a web service that returns one string back when a call is made?
I'm looking free, easy, works out of the box type of thing with minimum setup ... preferably don't want to use any kind of Microsoft tools.
There is a simple HTTP server that returns a response with "Hello, world" on the node.js home page
JSFiddle has a free web service tailored specifically for testing web service calls. The response given back is based on the parameters passed in.
Related
My project has gotten into web services lately, but our QA team has a request to be able to set up a clone client and clone web service so that they can issue a request from the clone client to the real web service and from the real client to the clone service to test the real pieces individually.
The clone client to real web service part is easy, I just wrap the generated client in a main() app that picks up data to send that the test team specifies. But the service part is confusing to me. How can I make a dummy service that just echoes out its requests to a log without affecting the real service? I want the real client to use the same generated client code, just point the soft-coded URL to the URL of the dummy.
If I define a new web service with identical names and signatures to the real service, can the real client hit the dummy with just a URL change? Or is it more complicated? Am I barking up the wrong tree?
Re: Making a dummy service
This would actually be called making a "mock" service or a web service "stub". You don't even technically have to code it - you can use tools. For example, SoapUI has the ability to import a WSDL and create a mock service. The have some other discussion of mock services as well - they can be used both to test the client application (or to simply develop it before the back-end resources are ready or available). To use a WSDL-based service stub you would simply change the endpoint of your client-under-test to the stub instance. SoapUI will show you (and let you configure) the stub's endpoint URL.
The trendy term for service mocking and stubbing is "service virtualization" (not to be confused with server virtualization as in virtual machines). Searches using this terminology will find you even more powerful (and expensive) tooling.
Re: Just a URL Change
Yep, for the most part. So long as the XML namespaces are the same and the WSDL is the same (minus endpoint URL) you should be fine. Since the WSDL acts as an interface contract, the stub MUST accept those same inputs and produce those same outputs. How it does so, of course, is up to you.
PS - free extra advice - Don't code a dummy client. Use tools (I'll use SoapUI again as an example free tool) to make your web service testing more robust and repeatable. You can create test suites with sample SOAP requests, add assertions on how the service should behave, and best of all - your investment in time of creating a test project can be shared across team members, cutting down time to test setup and making sure testing is thorough and repeatable. If you code a client, every tester/user of the test client will have their own way of testing, response inspection will probably be manual, and you'll notice when your best QA tester goes on vacation because regressions slip into the web service product. Repeatable testing can nix this, and tool based automated functional testing is the bees knees. You're already on the right path by testing the pieces individually.
I've used Selenium to do lots of UI testing from the browser. If you have a web service behind the Java jsp page i.e. in a servlet, you can test it from Selenium.
Can Selenium be used to test a B2B web service i.e. a web service called from a backend that has no browser UI component?
I have used SOAPUI to do this kind of testing in the past but our test department is trying to standardise on Selenium.
You can but I would not recommend it. If the page is returning XML, you won't be able to use the standard Selenium calls to verify what is happening as you won't have access to the DOM. If its returning plain text for JavaScript then you will struggle with verifying the output.
This is a definite case of using the right tool for the job and Selenium is not the right tool for testing web services. I would use soapUI or just use some http library to call the service URL and then verify the results.
If they are looking to standardise they need to standardise tools for their purpose. Selenium for UI, soapUI for webservices,XUnit Framework for unit and integration.
You can, but it's really not the right tool for the job. It's like trying to hammer a nail into a piece of wood using a stapler instead of a hammer.
That said, probably the most appropriate way to create a page with all your input parameters which could do the call for you and echo the results back into a html element. If the service is meant for AJAX calls then this is probably the ideal solution for your service.
The correct approach would be to use a unit testing framework and create a test harness which you can push your parameters into, execute the service call and retrieve the results in a meaningful way for assertion.
I am a novice in web services. I am totally new to testing web services.
A new project demands that I test the web services, and the customer is in favor of any open source tool.
What is the approach to testing web services?
Also Please suggest a tool(with minimal scripting) to test web services?
Check out SoapUI - one of the best web service test tools - plus it's free!!
They also have a "Pro" version which costs - you can do more stuff, like load testing etc., but the free version is quite good enough for most of your testing, I'd say!
Given a WSDL (online or stored as file), it'll create stubs for each method, which you can then use to create requests (as XML), fill in the blanks (the parameter values), and then you can send off your request to the web service and see what comes back as a response.
SoapUI also allows you to write scripted tests than can be run over and over again.
Excellent tool - can't praise it enough!
Marc
Additionally you could use Firefox Poster in order to test your web service by passing XML-packets manually.
Check it here:
FF Poster
SoapUI is a great tool to test SOAP webservices. It allows you to test a SOAP client or a SOAP server.
Another very useful tool is Fiddler. Fiddler isn't necessarily aimed at testing webservices (it's a HTTP debugger), but since SOAP webservices run over HTTP, you can use it to testing. Another very important advantage of using Fiddler is the fact that you can test REST webservices also.
You might want to consider robot framework. It is a generic, keyword-driven testing framework. There are libraries for testing REST and SOAP based web services. It can also be used to test web pages (via a selenium library), databases, and a whole lot more.
robotframework has a ton of built-in keywords, and there are additional libraries that do much more. You are also able to develop your own keywords in python, java, .NET languages, or any other language.
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.
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.