Datasource: fetch via GET, JSON response, possible?

[twelve17]

I am using SmartGWT 2.2.

I have a server side REST resource that accepts a GET request. No parameters or body are needed for this particular resource.

The resource can return XML or JSON, depending on the "Accept" header provided in the request.

For the life of me, I cannot seem to set up the Operation Binding to result in the request to have a "Accept" header of "application/json". I've tried using both RestDataSource as well as the base DataSource.

The operation binding looks like this:

   OperationBinding fetch = new OperationBinding(DSOperationType.FETCH, "/my/get/based/resource");
        fetch.setDataProtocol(DSProtocol.GETPARAMS);
        fetch.setDataFormat(DSDataFormat.JSON);

        // my datasource created earlier
        ds.setOperationBindings(fetch);

I then read somewhere in the javadoc that the "setDataFormat" just prepares the datasource for what to expect back, as opposed to actually preparing the request to specify the data format. So I then tried explicitly setting the header in the request object:

        DSRequest request = new DSRequest();
        request.setOperationType(DSOperationType.FETCH);
        Map<String, String> headers = new HashMap<String, String>();
        headers.put("Accept", "application/json");
        request.setHeaderData(headers);
        fetch.setRequestProperties(request);

Regardless of the above, looking at the GET trace in firebug shows this as the "Accept" header:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.

Any help would be appreciated. Thanks!

Alex

[Isomorphic]

Do you find that this differs by browser? Browsers will prevent certain headers from being set in an XMLHttpRequest, so what is likely going on is that SmartGWT provides your specified headers to the browser, but the browser declines to use them.

You could test by providing any other header and verifying that it is sent.

[twelve17]

Do you find that this differs by browser? Browsers will prevent certain headers from being set in an XMLHttpRequest, so what is likely going on is that SmartGWT provides your specified headers to the browser, but the browser declines to use them.

You could test by providing any other header and verifying that it is sent.

Thanks for the quick reply. I did some reading online and found this part of the XHR spec. Perhaps this is what you wrote about regarding browsers ignoring certain headers?

http://www.w3.org/TR/XMLHttpRequest/...theader-method

Anyway, I assumed you were, so I did the following.

1. Set up my "fetch" operation binding with a totally different, bogus, and hopefully non-problematic header that I hope the browser will not prevent:

 OperationBinding fetch = new OperationBinding(DSOperationType.FETCH, "/my/service/url");
        fetch.setDataProtocol(DSProtocol.GETPARAMS);
        fetch.setDataFormat(DSDataFormat.JSON);

        DSRequest request = new DSRequest();
        request.setOperationType(DSOperationType.FETCH);
        Map<String, String> headers = new HashMap<String, String>();
        headers.put("X-IceCreamFlavor", "chocolate/cookies");
        request.setHeaderData(headers);
        fetch.setRequestProperties(request);

2. I tried with the following browsers under Linux:

- Google Chrome 6.0.472.55
- Mozilla Firefox 3.6.9

Neither seemed to have sent this header.

Chrome sent:

GET /my/service/url HTTP/1.1
Host: 127.0.0.1:8888
Connection: keep-alive
Referer: http://127.0.0.1:8888/Foo.html
Cache-Control: max-age=0
If-Modified-Since: Thu, 1 Jan 1970 00:00:00 GMT
Accept: */*
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.55 Safari/534.3
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: JSESSIONID=njhcxo9lj88r

Firefox sent:

GET /my/service/url HTTP/1.1
Host: 127.0.0.1:8888
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100825 Ubuntu/10.04 (lucid) Firefox/3.6.9
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
If-Modified-Since: Thu, 1 Jan 1970 00:00:00 GMT
Referer: http://127.0.0.1:8888/Foo.html?gwt.codesvr=127.0.0.1:9997
Cookie: JSESSIONID=mnu66p84xltn

Perhaps I am using the wrong API to set the header correctly? Or maybe this is the wrong approach? I do see that another approach for driving content type from the server is to use different "extensions" on the url, i.e. /get/foo.json or /get/foo.xml, and thus the higher priority XML "Accept" value is effectively ignored.

Cheers,

Alex

[Isomorphic]

On rereading this we realize the issue is that dsRequest.headerData applies only to SOAP headers -- for general HTTP headers you need to use rpcRequest.setHttpHeaders() instead.

Sorry for the confusion, and let us know if you can't get that to work

[twelve17]

That did it! Sorry for the confusion on my end. I probably overlooked the difference in the method name. Thanks for your help. For the record, the "Accept" header does get sent, at least by Firefox.

Cheers,

Alex