RPC vs HTTP requests
Pion
http://code.google.com/webtoolkit/doc/latest/DevGuideServerCommunication.html#DevGuideRemoteProcedureCalls
- article mentions about RPC and HTTP techniques.
I am wondering what the pros and cons using RPC vs HTTP (doGet(),
doPost()) requests?
Most of the GWT samples are based on RPC. Is RPC technique a better/
recommended way?
Thanks in advance for your help.
Lucas Vargas Freitas Ventura
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
--
Lucas V. F. Ventura
Ciência da Computação - UFRJ
Pion
states, "First, because of the single-threaded execution model of most
web browsers, long synchronous operations such as server calls can
cause a JavaScript application's interface (and sometimes the browser
itself) to become unresponsive. To prevent network or server
communication problems from making the browser "hang", GWT allows only
asynchronous server calls. When sending an HTTP request, the client
code must register a callback method that will handle the response (or
the error, if the call fails)."
Based on the statement above, my understanding is that the http
request is also an async.
On Jan 2, 5:46 pm, Lucas Vargas Freitas Ventura
<lucasvfvent...@gmail.com> wrote:
> HTTP requests are synchronized methods, and RPC are a asynchronized method.
>
> I think that RPC is the google's implementation of HttpXmlRequest.
>
> For Rich Internet Application you will use a lot of ajax, so you will use
> all most of time RPC.
>
> (Sorry, my english isn't good).
>
>
>
> On Sat, Jan 2, 2010 at 8:46 PM, Pion <onlee2...@gmail.com> wrote:
> > "Communicate with a Server" -
>
> >http://code.google.com/webtoolkit/doc/latest/DevGuideServerCommunicat...
> > - article mentions about RPC and HTTP techniques.
>
> > I am wondering what the pros and cons using RPC vs HTTP (doGet(),
> > doPost()) requests?
>
> > Most of the GWT samples are based on RPC. Is RPC technique a better/
> > recommended way?
>
> > Thanks in advance for your help.
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > To post to this group, send email to google-we...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>
Yozons Support on Gmail
Lucas Vargas Freitas Ventura
RPC serializes basic java objects and your javabeans based on them, giving you a nice model for programming since in GWT it's all Java when programming. If you use HTTP, you can post name-value string pairs, and then you'll have to process the response string. It's just much less powerful, but may work fine for you. I mean, the traditional web browser uses this technique, but it does mean handling errors and URL encoding your data to send and parsing the response.
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
Jan Ehrhardt
So for me RPC makes only sense in some special use cases. HTTP with JSON is supported by most server side frameworks, it is much more flexible (e. g. JSON-P for cross domain requests) than RPC and thanks to JavaScript overlays it isn't more work to do (even less work with Spring 3.0, since Spring RPC integration is more pain).
Jan Ehrhardt
ahha...@gmail.com
a java based server code.
I needed to work on anything else.
That left me with the http / Json, it was not hard to be done but you
will need to take care of a lot more things...
On the other hand, if you don't mind using java on the server, it will
probably make your life easier.
One of the things I like the most about the HTTP way is that, after
having spent some time to write and test my engine on the client, I
can reuse my engine to communicate with any server.
But since it was a my first app with gwt, it was not really an nice
start...
On Jan 3, 1:46 am, Pion <onlee2...@gmail.com> wrote:
> "Communicate with a Server" -http://code.google.com/webtoolkit/doc/latest/DevGuideServerCommunicat...
Duong BaTien
I am with you on the separation of concern between GWT client and server
using JSONP. Have you look at http://google-web-
toolkit.googlecode.com/svn/javadoc/2.0/index.html in GWT trunk and work
out a solution with a REST framework such as Restlet. Please share your
experience.
Duong BaTien
DBGROUPS and BudhNet
> To post to this group, send email to google-web-
> too...@googlegroups.com.
> To unsubscribe from this group, send email to google-
> web-toolkit...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?
> hl=en.
>
>
>
>
>
> --
> Lucas V. F. Ventura
> Ciência da Computação - UFRJ
>
>
> --
>
> You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group.
>
> To post to this group, send email to google-web-
> too...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-
> toolkit+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "Google Web Toolkit" group.
> To post to this group, send email to google-web-
> too...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-toolkit
> +unsub...@googlegroups.com.
Nathan Wells
GWT has gone to great lengths (to the point of being annoying in my
case) to ensure that a developer knows exactly where the code is that
is being written.
As far as the RPC vs RESTful debate, I think most everyone would agree
that REST is better from an abstract interface perspective. However,
in many cases RPC is faster to develop in, GWT RPC is a faster
transport, and makes life easier than json and overlay types. This is,
of course, IMHO.
Not that I'm saying GWT-RPC is a silver bullet. I'm just saying if the
following are true for you, then GWT-RPC may be good for you:
(1) My GWT-based webapp is (and will always be) the only consumer of
my server resources (i.e. servlets)
(2) A Java server will always be used
(3) In a tradeoff between perfect design and perfect performance, I
tend towards performance.
On Jan 3, 9:21 am, Duong BaTien <duong.bat...@gmail.com> wrote:
> Hi Jan:
>
> I am with you on the separation of concern between GWT client and server
> using JSONP. Have you look athttp://google-web-
Jan Ehrhardt
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
Sripathi Krishnan
Server Platform
- If you are using a non-java platform on server side, GWT RPC is not an option.
- If you want to integrate with existing thirdparty services or do mashups, you'd have to use REST. In that case, you may want to use REST for your services as well, just to be consistent.
- If you are already using a json -> java -> json library, you are perhaps already invested in REST, and so should stick to that approach.
- If you want to reuse services with other non-GWT projects, REST with JSON & XML is the only option.
- GWT RPC wins hands down. Its easy to get started, and provides a great abstraction.
- With RPC, the developer feels he is invoking a normal
java method. With REST apis, the developer has to know that he is
dealing with HTTP. Of course you can have an abstraction over REST, but
then you'd have to write that abstraction layer.
- REST with JSON requires a Javascript overlay object, which requires some hand-coding. It isn't too bad, but slows new developers if you compare with RPC.
- Client Side - REST with JSON wins over RPC. Browsers are exceptionally good at json parsing. It is going to be much faster than GWTs serialization/deserialization mechanism. This is applicable only if you use javascript overlays. JSONArray/JSONObject/JSONValue classes don't give you this performance benefit.
- Server side, comparison is a bit more difficult. A lot depends on how you are generating your JSON stream. GWT RPC uses reflection, so a framework that avoids reflection to generate JSON is going to be faster - but that may be an oversimplification.
- Both have a great separation of concern. Its largely a perception issue.
- REST obviously has a great distinction between client and server.
- RPC also has a great separation, though it doesn't appear at first. You really cannot intermingle client and server code even if you want to - the code will just not compile. A lot of people think that just because it is java, you can use any server side code. In reality, the only way to communicate is via well-defined RPC interfaces.
- This is a moot point. Both approaches are inconvenient.
- With GWT RPC, you cannot send persistent objects across the wire. But then, you can't do that with REST either. You really have to convert server side objects into something the client can understand, that's the state of technology.
- The typical workaround is creating simple beans that wrap the underlying hibernate/database object. Its a pain, but its no different from what you'd end up doing with REST. The javascript overlay object you create on the client is also a bean that wraps the underlying json - and you still have to create it manually.
--Sri
Jan Ehrhardt
Jeff Chimene
Thanks.
I have a question:
<snip>
Performance
- Client Side - REST with JSON wins over RPC. Browsers are exceptionally good at json parsing. It is going to be much faster than GWTs serialization/deserialization mechanism. This is applicable only if you use javascript overlays. JSONArray/JSONObject/JSONValue classes don't give you this performance benefit.
Report.set(JSONParser.parse(response.getText()).isObject().getJavaScriptObject());
Where Report is defined as follows:
public class Report extends JavaScriptObject {
protected Report() {}
public final static native Report get() /*-{
return $wnd.Report;
}-*/;
public final static native void set(JavaScriptObject value) /*-{
$wnd.Report = value;
}-*/;
}
I don't see any other way to avoid unsafe parsing.
Comments?
<snip>
Thomas Broyer
>
> > - Client Side - REST with JSON wins over RPC. Browsers are
Use JsonUtils.unsafeEval() to avoid the unused JSONObject created by
JSONParser.parse(), and then just use .cast() to turn the JSO into a
Report (unless of course you want a singleton in the $wnd.Report
global JS variable):
Report myReport = JsonUtils.unsafeEval(response.getText()).cast();
Jeff Chimene
Hi Thomas:
Isn't an aspect of unsafeEval() that it's unsafe? Is JSONParser() also
unsafe? Or do I always want to add comments to the cargo at the
generator, strip such comments at the receiver and call unsafeEval() (&
its equivalent on the server)
From the JSONParser() code, I get the impression that it tries to
differentiate among arrays, strings, &c. I thought that such behavior
was A Good Thing.
Thomas Broyer
On 4 jan, 19:23, Jeff Chimene <jchim...@gmail.com> wrote:
> On 01/04/2010 10:57 AM, Thomas Broyer wrote:
>
> > Use JsonUtils.unsafeEval() to avoid the unused JSONObject created by
> > JSONParser.parse(), and then just use .cast() to turn the JSO into a
> > Report (unless of course you want a singleton in the $wnd.Report
> > global JS variable):
>
> > Report myReport = JsonUtils.unsafeEval(response.getText()).cast();
>
> Hi Thomas:
>
> Isn't an aspect of unsafeEval() that it's unsafe? Is JSONParser() also
> unsafe?
Yes, both use a plain JS eval() to "parse" the JSON string. JSONParser
has room for enhancement in using native JSON parsing in browsers that
support it (IE8, FF3, Safari 4 and Chrome), whereas unsafeEval is
likely to always use eval().
I built my own JSON module that uses JSON.parse() when available
(using deferred binding to never try it in IE6/7, old-mozilla and
Opera, and always use it in IE8) and fallback to JsonUtils.unsafeEval
() otherwise.
> Or do I always want to add comments to the cargo at the
> generator, strip such comments at the receiver and call unsafeEval() (&
> its equivalent on the server)
I don't understand the "comments" thing (I think I understand the
"how", but I clearly don't get the "why")
> From the JSONParser() code, I get the impression that it tries to
> differentiate among arrays, strings, &c. I thought that such behavior
> was A Good Thing.
JSONParser only tries to provide "strong typing" by some kind of
"introspection/reflection", that you obviously don't have with JSOs,
but is it really needed?
Even with JSONParser, you'll generally don't handle the "error path"
and live with potential NPEs (in your snippet, what if the eval'd text
isn't an object but an array?), which finally leads to doing
computations about the data type that you don't really care in the
end.
It's generally not worth paying the JSONValue "tax" of data type
"discovery". The only thing that's missing with JSOs is an easy way of
doing data type discovery in case the JSON format allows for different
types of data (e.g. in an object, the value of key "foo" can be a
string or an array of strings; an array of numbers or strings; etc.)
K.R.Arun
Although I'm not as much experienced as most of you are, I'd like to
share some views of mine,
I developed a GWT 1.7 based application for My final year Project in
CS graduation course.
It's a fun to develop a full blown RIA application without any JS from
my side. I used RPC because web development was totally alien to me at
that time. And the get, post thing is not my concern, because of RPC.
*RPC is simple to use*
But when I need to pass data from server, (I used JPA) I have to
create another layer of classes for RPC representation (I'm not happy
with that, it's clearly against DRY).
Then I thought to host it, so public can access it. :-( Java hosting
is costly. And since I uses RPC (that's specific to Java), now I have
to reimplement it using Http method.
*RPC is less flexible*
* use http, then you can use virtually all server frameworks, may be
it's web2py(my current choice), PHP, grails, RoR, Python frameworks,
and Java itself (if you need), etc., *
Arun
Jan Ehrhardt
protected Report() {}
return this.name;
}-*/;
public final static native void setName(String name) /*-{
this.name = name;
}-*/;
}
--
Jan Ehrhardt
Jeff Chimene
Hi Jeff,I don't know why you're binding a Report object to $wnd, but in a standard case JSON usage would look the following way:
Hi Jan,
I want the object to exist across different class instantiations. Ordinarily, I'd use gin to inject a singleton where needed, but I couldn't get that to work w/ JSNI. Perhaps it does w/ 2.0. It wasn't the best example for a post to the group, but it's what I had at hand.
Jeff Chimene
On 4 jan, 19:23, Jeff Chimene <jchim...@gmail.com> wrote:
> On 01/04/2010 10:57 AM, Thomas Broyer wrote:
>
> > Use JsonUtils.unsafeEval() to avoid the unused JSONObject created by
> > JSONParser.parse(), and then just use .cast() to turn the JSO into a
> > Report (unless of course you want a singleton in the $wnd.Report
> > global JS variable):
>
> > Report myReport = JsonUtils.unsafeEval(response.getText()).cast();
>
> Hi Thomas:
>
> Isn't an aspect of unsafeEval() that it's unsafe? Is JSONParser() also
> unsafe?
Yes, both use a plain JS eval() to "parse" the JSON string. JSONParser
has room for enhancement in using native JSON parsing in browsers that
support it (IE8, FF3, Safari 4 and Chrome), whereas unsafeEval is
likely to always use eval().
I built my own JSON module that uses JSON.parse() when available
(using deferred binding to never try it in IE6/7, old-mozilla and
Opera, and always use it in IE8) and fallback to JsonUtils.unsafeEval
() otherwise.
Hi Thomas,
I don't have the resources to delve into deferred binding right now. I've seen a project (earlier in this thread) that looks interesting in that regard.
> Or do I always want to add comments to the cargo at the
> generator, strip such comments at the receiver and call unsafeEval() (&
> its equivalent on the server)
I don't understand the "comments" thing (I think I understand the
"how", but I clearly don't get the "why")
The why is explained here:
http://groups.google.com/group/google-web-toolkit/web/security-for-gwt-applications
under
JSON and GWT
Protecting Your Single-Site Application
> From the JSONParser() code, I get the impression that it tries to
> differentiate among arrays, strings, &c. I thought that such behavior
> was A Good Thing.
JSONParser only tries to provide "strong typing" by some kind of
"introspection/reflection", that you obviously don't have with JSOs,
but is it really needed?
Even with JSONParser, you'll generally don't handle the "error path"
and live with potential NPEs (in your snippet, what if the eval'd text
isn't an object but an array?), which finally leads to doing
computations about the data type that you don't really care in the
end.
In that situation, I'd like a runtime error. Something bad happened, and the app should fall over. Since I cannot predict what EvilCo will devise in the future w/r/t JSON attacks, I pay the "tax" as a way of precisely determining at run time the type of structure I expected when I wrote the code. Note that this code is not part of a mashup. I have control over the JSON at the sender and receiver.
It's generally not worth paying the JSONValue "tax" of data type
"discovery".
As noted above, I'm doing this as a way of ensuring that, at runtime, the structure I expected is the structure I received.
The only thing that's missing with JSOs is an easy way of
doing data type discovery in case the JSON format allows for different
types of data (e.g. in an object, the value of key "foo" can be a
string or an array of strings; an array of numbers or strings; etc.)
Yeah, that's one of the issues I've been facing.
Jan Ehrhardt
Jeff Schnitzer
over everything everyone else has said in this thread (most of which I
disagree with) and address the original poster directly:
Since you're asking this question, I presume you are a novice with
GWT. In this case, your path is clear - use GWT-RPC. While REST/JSON
has its uses, GWT-RPC is far easier to learn and far easier to use.
It's also much more robust in a fast-changing codebase; the client and
server use the same interfaces so the compiler keeps them in sync.
It's not an all-or-nothing choice; my app provides JAX-RS REST
services to iPhone clients but all the GWT<->server communication is
GWT-RPC because it's 10X faster to iterate.
If you're even remotely wondering whether you should use the GWT-RPC
system or roll your own REST APIs, you should be using GWT-RPC. It's
pretty much that simple.
Jeff
Thomas Broyer
On Jan 6, 7:48 am, Jan Ehrhardt <jan.ehrha...@googlemail.com> wrote:
> Hi Jeff,
>
> I didn't try it yet, but a subclass of JavaScriptOject should
> be instantiated by 'GWT.create(Report.class)'. Gin resolves these
> dependencies automatically without any configuration (the same with
> Constants for i18n, ImageBundles, etc.). You can additionally try
> 'bind(Report.class).in(Singleton.class)' (I had problems using Singleton
> annotations in the past).
It won't work. I mean, GWT.create(someJSO.class) won't work. You just
cannot "instantiate" a JSO, though you can eventually cast() a
JavaScriptObject.createObject() or JavaScriptObject.createArray().
> I think, it should work, but even a Factory class that does the
> instantiation an returns a singleton object might be better than using
> native JavaScript to bind it to $wnd object, since it's important to hold
> everything in the GWT 'sandbox'.
Yes, a Provider would be the way to go.
Jeff Chimene
Hi Thomas,
Yes, we've had this discussion in the past. Providers are a good solution.
I understand that
is sufficient.
I have gotten Providers to work in the past.
However, I want any JSO to work reliably and with the same pattern. I found I needed a $wnd object to achieve such consistency. For that reason, the Provider seems redundant (since I'm already creating a "static" (via GWT $wnd, not the Java storage qualifier) object and static get()/set() methods on that object). Note that field references (name, address, &c) are not static;just the getter/setter on the base object.
Note also that I implement a MockReader and MockWriter w/ such objects. The underlying JSO does not change, only the routine that supplies/retrieves data using such objects. That was another reason to select this technique. I found thst writing the object in a MockWriter and reading it in a MockReader was impossible w/o $wnd esp. when mocking XHR methods.
Jerome Louvel
I'm jumping a bit late in the discussion but as Duong pointed out, our
Restlet Framework has a special edition for GWT (as well as Android
and GAE) and supports RESTful interactions between GWT clients and
servers written in Restlet or other technologies.
Recently, we have even written the equivalent of GWT-RPC for REST/
HTTP, reusing the same serialization logic, therefore providing the
best of both worlds: the productivity and abstractions of annotated
Java interfaces and the reusability and interoperability of a RESTful
backend!
You can read more details about those features in this recent blog
post:
"Restlet, a RESTful middleware for GWT, GAE and Android"
http://blog.noelios.com/2009/12/17/restlet-a-restful-middleware-for-gwt-gae-and-android/
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com