GWT and REST

[Matt Raible]

I posted a much longer message yesterday, but I can't find it on this
list. I apologize if this shows up as a duplicate.

Is there a way to easily use a REST backend with GWT? I tried GWT-REST
[1]. It works, but it seems to be centered towards Rails (I'm using
Grails) and it suffers from the SOP issue [2].

JSONRequest [3] looks promising for cross-domain support, but I can't
get it to work either. The provided examples work, but not my simple
hello world that returns:

{"response":"Hello World!"}

Also, the example implementation only has GET support, not PUT, DELETE
or POST. I can post my REST backend on the public internet if anyone
is interested in seeing the issues I'm having.

Thanks,

Matt

[1] http://code.google.com/p/gwt-rest/
[2] http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/FAQ_SOP
[3] http://www.gwtsite.com/how-to-access-web-services-with-gwt/

[walden]

Matt,

The short answer: No, there isn't an easy way to use a REST backend...
(ever).

REST is not for ease of use; it's for independent evolvability. The
price for that is extra code for parsing and interpreting responses on
the client (the REST client, that is).

Many don't seem to realize that a GWT client tightly coupled to its
RPC server component is not unRESTful, unless the RPC message design
is stateful and/or poor granularity for the network. The tight
coupling itself is not an evolvability concern because the client is
not an independent project; it's "code on demand" provided by the very
server it is going to interact with.

If I were you, I would design an elegant GWT client using GWT-RPC and
let the RPC service proxy requests to the REST service. You probably
built your REST service for a different client and now want to reuse
it, which is great. However, I would pay the price for adaptation on
the server if I were you.

These would be my two cents.

Good luck,

Walden

[Jason Essington]

On Jul 21, 2008, at 8:31 AM, Matt Raible wrote:

>
> I posted a much longer message yesterday, but I can't find it on this
> list. I apologize if this shows up as a duplicate.
>
> Is there a way to easily use a REST backend with GWT? I tried GWT-REST
> [1]. It works, but it seems to be centered towards Rails (I'm using
> Grails) and it suffers from the SOP issue [2].

The SOP issue is a brows security thing and not a GWT issue. Any
attempt to initiate an XMLHTTPReaquest from a browser will be bound by
SOP.

> JSONRequest [3] looks promising for cross-domain support, but I can't
> get it to work either. The provided examples work, but not my simple
> hello world that returns:
>
> {"response":"Hello World!"}

you would need to bind a callback to the global (window) scope.

> Also, the example implementation only has GET support, not PUT, DELETE
> or POST. I can post my REST backend on the public internet if anyone
> is interested in seeing the issues I'm having.

This is due to the way cross origin requests work. you insert a script
tag that fetches the data, this is necessarily a GET request.

There does seem to be a market for an easy cross origin way to make
requests, but that does require some coupling of client/server code.

-jason

[precog]

We use a restful backend for some of our stuff, but we don't parse the
data, only render within a frame (no data parsing). Unfortunately,
you don't get a handle to the frame contents.

Some more hacky solutions:

1 - Have an RPC talk to your REST implementation (probably not the
best solution).
2 - Build your ajax calls within the gwt's native javascript, which
the GWT function can then call (better).

[Jim Freeze]

Was there a question here?

--
Jim Freeze

[Thomas Broyer]

On Jul 21, 4:31 pm, Matt Raible <mrai...@gmail.com> wrote:
> I posted a much longer message yesterday, but I can't find it on this
> list. I apologize if this shows up as a duplicate.
>
> Is there a way to easily use a REST backend with GWT?

Depends what you mean by "easily"...

We use "RESTful web services" that return JSON. In our client-side GWT
code, each object that can be returned by the server is a
JavaScriptObject subclass and we use eval('(' + response.getText() +
')') in JSNI to parse the JSON into our JavaScriptObject (builds a few
less objects than
JSONParser.parse(response.getText()).isObject().getJavaScriptObject()).
For arrays, I use a JsArray class that's a JavaScript Array as a
JavaScriptObject subclass (there's one now in GWT, to be released in
1.5 RC2: http://code.google.com/p/google-web-toolkit/source/browse/releases/1.5/user/src/com/google/gwt/core/client/JsArray.java
)

The eval() thing is done in a specialized RequestCallback which
handles errors too (response.getStatus() != 200 and
JavaScriptException raised by the eval()).

We do not POST JSON or the like, only application/x-www-form-
urlencoded (built by hand or by the browser with a FormPanel) or
multipart/form-data if we need file uploads; but this is due to our
server-side framework which has some major (and annoying) constraints/
restrictions.
Actually, we're generating JSON somewhere in our app (once only, in a
ery specific case), constructing a JSONArray, adding to it and then
using its toString to get the JSON back.

I didn't find it "hard" to build our "micro framework", but others
will probably won't find it "easy" either...