Do I need a separate Web Client?

[Mimi Tam]

Dear all,

(I got no response from Forums where I also posted this question)

My "demo" RESTFUL Web Service is running fine on my local Tomcat. As far as I am concerned, I can use any Browser as a client to access and consume its Services simply by specify a URL to it e.g. http://localhost/demo brings up the Home page.

Now, "demo" is running on a Tomcat in the network. I expect any browser opened up within this network to act as a Web Client simply by specifying a URL to it e.g. "http://192.168.xx.xx/demo" or "http://192.168.xx.xx:8080/demo" to bring up the Home page. Am I wrong?

Do I need to write a RESTFUL Web client using RestTemplate or any good old web client in order to access and consume "demo"'s Web Services? Under what circumstance do I need a separate RESTFUL web client written up as a consumer? In a Remote access situation?

As far as I am concerned, "demo" being a RESTFUL Web Service already has a Web client built in. If I send an HTTPRequest from a client machine to "demo" running in a network Tomcat, the HTTPResponse will be received by the client machine. The business logic to process this HTTPResponse message can be written inside this Web Service "demo" module as well. Am I totally confused?

Please straighten me out. I need your advice.

Many Thanks.

[William Brogden]

The whole point about REST is that the simple GET, POST, etc. HTTP requests have simple definitions to get/modify etc resources according to the rules of HTTP. Nothing magic is involved.

The type of client obviously depends on the type of resource returned.

SO - the big question is - what type of resource does your service return and what do you expect a client to do with it?

Bill

[Mimi Tam]

Thank you so much for your reply, Bill.

"demo" is a Web Service running in a Server (Tomcat, JBOSS) so anyone with a browser can access it via the Internet and to fiddle with a back-end MySQL database (i.e to retrieve, store, update, merge data) .

My clients are actually wireless devices (phone, pad, laptop, whatever) and they send HTTP Requests to "demo", "demo" sends forms/web pages back to the browser client for input, process it and return a HTTP Response to the URL of the sender. Both HTTP Request and Response are in XML format.

I am using XStream for my XML conversion and it seems to work fine so far on the server side. Of course currently, I am running Server-side logic and Client-side logic together when running from the same machine, like a loopback.

The idea is for the Web Service to receive any HTTP Requests coming in and sends a HTTP Response back to the URL of the sender.

In this scenario, do I need a separate web client (web application) in order to consume the "demo" Web Service running on my Tomcat?

Am I using the right approach?

Your help is and will be greatly appreciated.

[R Srini]

Hi. My understanding of a service is that it performs a function and then returns a result with just the data - not the entire formatted home page. For example, the following REST URL might return the sum of two numbers:

http://yourcompany.com/restfulservices/addTwoNumbers?firstnumber=20&secondnumber=30

Yes, put a SOAP envelope around it, etc. But it returns a result, say in XML format.

Now, in your case, http://localhost/demo brings up the home page. Correct me if I am wrong in understanding your situation ... What you have is something like this: Open this URL - http://search.yahoo.com/search?p=java - in a browser, and Yahoo shows you the search results page (and Yahoo may have other services returning search results). If this is your situation where your service returns navigable web pages in a browser, and its what your client needs, then all is well. If your RESTful services merely return results in XML, then your client will need to pay you to build a client program. Hope that answers your question.

[Mimi Tam]

Thank you very much for your reply.

I have wired clients and wireless clients. For wireless clients, the only communication between Server and client is via HTTP messaging, message body is in XML format.

The wireless client (iPhone, Blackberry, Android...) can do whatever they want with the returned data.

My wired clients (also for testing purposes) are Web Browser users. They URL into the Server and see the Home Page. they clicked something and a customized HTTP Request Form shows up for them to enter data. This HTTP Request Form is the View ('V' of the MVC) that the Server presents.

User done entering data and click a SEND button. The Server than use the Form data to compose a HTTP Response in XML format to be sent back to the sender URL. For testing in wired connections via the Internet, the Server side returns a View of a customized HTTP Response message Form to display what data has been sent.

My Web Service is acting both as a Server and a Client because it is capable of receiving HTTP Request and sending HTTP Response back. Only for testing, the HTTP Response will be displayed on a web page to show the user what has been sent. This is also a View (i.e. the HTTP Response View) that the Server puts out under the MVC model.

For wireless endpoints, they send HTTP Request to Server and get back HTTP Response, that's it. The Server currently do the following:

....
public class HttpRequestController {		
	
	@RequestMapping(value = "/httprequest", method=RequestMethod.POST)
	public @ResponseBody String createResponse(@Valid HttpRequest, httpRequest) {
        ...... 
        httpRequest.persist();
        return httpRequest.createResponse(httpReqMsg1);	    
}

// Http Response Java POPO
public class HttpResponse {
....
        pubic String createResponse(httpRequest) {
           .......

        return this.toString;
}

Now, the Server returns a long string to be displayed on the screen. I will change it to return a HttpResponse View with data. That way, any browser accessing my Server will see Forms to enter data and Forms to see what they had sent.

Ultimately, the Service will have to distinguish between wired and wireless HTTP requests. For wireless request, under the MVC model, instead of returning a View (*.jspx) to the DefaultHandler() and display this View on the client browser, I think I will have to return NULL to get MVC to send back just a HTTP Response message to the sender URL (the wireless device).

There are a few things that I simply don't know how to go about doing it yet (using the MVC model). For now, I want to get the wired web client working (i.e. to consume my Web services, put the composed Response message onto a Form to be shown on the Requestor's browser.

In this scenario, do I need a separate Web Client?

Thank you so much for reading thru my problem.

Any help will be tremendously appreciate.

[William Brogden]

Still trying to zero in on exactly what your problem is.

IF you want the response to be treated and displayed as a string, you are already there.

IF you want the response to be parsed (XML, CSV, some other format) THEN will have to write some response handling code, which I suppose will be called a web client. There is no useful framework for REST clients as far as I know but it should be simple.

Ignore SOAP unless you absolutely have to have authentication/encryption/etc/etc

I think I will have to return NULL to get MVC to send back just a HTTP Response message to the sender URL (the wireless device).

Why not use HTTP response codes to communicate or just send an empty response body?

MVC is pretty intuitive, don't worry too much about it. The main thing is not to get your M tangled up with V and C.

At this point I would have a white-board covered with some sort of flow diagram.

Bill

[Mimi Tam]

Dear Bill,

Thank you so much for all the useful advice and explanation. They are most helpful. I really appreciate it.

"...IF you want the response to be treated and displayed as a string, you are already there.

IF you want the response to be parsed (XML, CSV, some other format) THEN will have to write some response handling code, which I suppose will be called a web client. There is no useful framework for REST clients as far as I know but it should be simple....

I am indeed already there as the Server App is displaying the HTTP Response returned by it to the sender URL on the screen as formatted text. I am going to create a Response View (Show) so that the Server App can return this View instead of a String for the browser user to see it more easily.

Nevertheless, I have 2 scenarios:

1.) For a Web Client (vs Wireless Client), I can return this Response View just like any other Views. No Problem

2.) For a Wireless Client, I am calling XStream to serialize the HTTP Response to XML before sending it out to the URL of the wireless endpoint.

I am doing both in my Web Server App. It sounds like that if the Browse User is not expected to do anything but simply to receive the HTTP Response either via a View constructed and sent back by the Server App (in which case, user simply sees a returned formatted web page) or for a wireless device, to receive the HTTP Response in XML format as is, then I don't need a Web Client.

The RESTFUL Web Client web site that talks about using the "RestTemplate" (http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/) is the scenario that I don't think mine resembles but just want to make sure.

From your clear and precise explanation, I am convinced that I don't need a separate Web client.

My very sincere THANKS!

[Mimi Tam]

Dear Bill,

I wrote: "...I think I will have to return NULL to get MVC to send back just a HTTP Response message to the sender URL (the wireless device)...."

Your response: "...Why not use HTTP response codes to communicate or just send an empty response body? MVC is pretty intuitive, don't worry too much about it. The main thing is not to get your M tangled up with V and C. ...."

Sorry, I was not clear here or I am just really confused. What I meant was that to have the Controller returning a View, a View will be displayed with the data model. In order for the Controller to not do anything (e.g. looking for a View to retutrn) but just send the HTTP Response message out, I thought the way to do it is to return NULL from the Controller and the Controller will know what to do.

For Web Client (wired):

public class HttpRequestController {		
	
	@RequestMapping(value = "/httprequest", method=RequestMethod.POST)
	public @ResponseBody HttpResponse createResponse(@RequestBody HttpRequest httpRequest) {
        if (httpRequest == null) 
        	throw new IllegalArgumentException("Am HTTP Request Message is required");
        httpRequest.persist();
        httpRequest.createResponse();
        httpRequest.httpResponse.persist();
        return "redirect:/httpresponse/" + httpRequest.httpResponse.getResponseId();    // returning the HTTP Response View - "Show" 
    }

For Wireless Client:

public class HttpRequestController{		
	
	@RequestMapping(value = "/httprequest", method=RequestMethod.POST)
	public @ResponseBody HttpResponse createResponse(@RequestBody HttpRequest httpRequest) {
        if (httpRequest == null) 
        	throw new IllegalArgumentException("An HTTP Request Message is required");
        httpRequest.persist();
        httpRequest.createResponse();
        httpRequest.httpResponse.persist();
        return null;         // <-------  returning  NULL here so that Spring knows to just send the the HTTP Response Message out
    }

Am I making any sense?

I always have doubt on the wireless client bit (2nd block above). Is that indeed the way to indicate in the Controller to Spring that this POST request has been handled (so no View to return) but will still send the @ResponseBody (after it automatically added an HTTP Header for me) to the HTTP Requestor URL for me?

Many THANKS for your help!