Re: RPC vs HTTP requests
Hi all, 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 -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
I normally try to stay out of religious wars, so I'm going to skip 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 On Sat, Jan 2, 2010 at 3:46 PM, Pion onlee2...@gmail.com wrote: Communicate with a Server - 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. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
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. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
On Wed, Jan 6, 2010 at 4:33 AM, Thomas Broyer t.bro...@gmail.com wrote: 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. Hi Thomas, Yes, we've had this discussion in the past. Providers are a good solution. I understand that Report report = obj.getJavaScriptObject().cast(); followed by report.getName() 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. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
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:
public class Report extends JavaScriptObject {
protected Report() {}
public final static native Report getName() /*-{
return this.name;
}-*/;
public final static native void setName(String name) /*-{
this.name = name;
}-*/;
}
An incoming JSON string looking like this
{name: My Report}
can be parsed the following this way
JSONObject obj = JSONParser.parse(response.getText()).isObject();
if(obj != null) {
Report myReport = obj.getJavaScriptObject().cast();
// do something with myReport
}
This has the benefit, that the object only lives as inside your GWT app,
instead of affecting other things.
On Mon, Jan 4, 2010 at 4:01 PM, Jeff Chimene jchim...@gmail.com wrote:
Sri,
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.
I've been using the following technique to use the JSON parsing in 2.0. I
don't see a specific example in the docs:
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
--
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
Oh, one mistake in my above sample:
The methods of the Report class shouldn't me static.
Regards
Jan Ehrhardt
On Tue, Jan 5, 2010 at 10:23 AM, Jan Ehrhardt
jan.ehrha...@googlemail.comwrote:
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:
public class Report extends JavaScriptObject {
protected Report() {}
public final static native Report getName() /*-{
return this.name;
}-*/;
public final static native void setName(String name) /*-{
this.name = name;
}-*/;
}
An incoming JSON string looking like this
{name: My Report}
can be parsed the following this way
JSONObject obj = JSONParser.parse(response.getText()).isObject();
if(obj != null) {
Report myReport = obj.getJavaScriptObject().cast();
// do something with myReport
}
This has the benefit, that the object only lives as inside your GWT app,
instead of affecting other things.
On Mon, Jan 4, 2010 at 4:01 PM, Jeff Chimene jchim...@gmail.com wrote:
Sri,
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.
I've been using the following technique to use the JSON parsing in 2.0. I
don't see a specific example in the docs:
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
--
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
On Tue, Jan 5, 2010 at 2:23 AM, Jan Ehrhardt jan.ehrha...@googlemail.comwrote:
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.
public class Report extends JavaScriptObject {
protected Report() {}
public final static native Report getName() /*-{
return this.name;
}-*/;
public final static native void setName(String name) /*-{
this.name = name;
}-*/;
}
An incoming JSON string looking like this
{name: My Report}
can be parsed the following this way
JSONObject obj = JSONParser.parse(response.getText()).isObject();
if(obj != null) {
Report myReport = obj.getJavaScriptObject().cast();
// do something with myReport
}
This has the benefit, that the object only lives as inside your GWT app,
instead of affecting other things.
On Mon, Jan 4, 2010 at 4:01 PM, Jeff Chimene jchim...@gmail.com wrote:
Sri,
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.
I've been using the following technique to use the JSON parsing in 2.0. I
don't see a specific example in the docs:
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
--
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
On Mon, Jan 4, 2010 at 7:22 PM, Thomas Broyer t.bro...@gmail.com wrote: 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* That said, some people advise JSON developers to employ an extra precaution besides the cookie duplication XSRF countermeasure. In this model, your server code would wrap any JSON response strings within JavaScript block comments. For example, instead of returning ['foo', 'bar'] you would instead return /*['foo', 'bar']*/. The client code is then expected to strip the comment characters prior to passing the string to the eval function. 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. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
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).
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'.
Regards
Jan Ehrhardt
On Tue, Jan 5, 2010 at 5:11 PM, Jeff Chimene jchim...@gmail.com wrote:
On Tue, Jan 5, 2010 at 2:23 AM, Jan Ehrhardt
jan.ehrha...@googlemail.comwrote:
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.
public class Report extends JavaScriptObject {
protected Report() {}
public final static native Report getName() /*-{
return this.name;
}-*/;
public final static native void setName(String name) /*-{
this.name = name;
}-*/;
}
An incoming JSON string looking like this
{name: My Report}
can be parsed the following this way
JSONObject obj = JSONParser.parse(response.getText()).isObject();
if(obj != null) {
Report myReport = obj.getJavaScriptObject().cast();
// do something with myReport
}
This has the benefit, that the object only lives as inside your GWT app,
instead of affecting other things.
On Mon, Jan 4, 2010 at 4:01 PM, Jeff Chimene jchim...@gmail.com wrote:
Sri,
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.
I've been using the following technique to use the JSON parsing in 2.0. I
don't see a specific example in the docs:
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
--
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-toolkit@googlegroups.com
.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
Hi Sripathi, I agree with that, except one addition to the point 'Ease of Use': REST requires to write JavaScript overlay classes, that's right. But RPC requires to write transfer object classes, if your domain objects are generated by a persistence framework. I would expect, that most projects use a persistence framework instead of doing the persistence by hand. So the benefit of sending Java objects directly to the browser becomes more theoretical point. Thus you'll have to write additional classes for transferring data in both cases, or you'll have to do the additional work by writing your own persistence layer (which is last I would recommend). Regards Jan Ehrhardt On Mon, Jan 4, 2010 at 2:40 AM, Sripathi Krishnan sripathi.krish...@gmail.com wrote: At the expense of repeating a few points already mentioned, here's my summary - * Server Platform* 1. If you are using a non-java platform on server side, GWT RPC is not an option. 2. 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. 3. If you are already using a json - java - json library, you are perhaps already invested in REST, and so should stick to that approach. *Reusability of Services* - If you want to reuse services with other non-GWT projects, REST with JSON XML is the only option. 1. *Ease of Use / Abstraction* - 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. *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. - 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. *Separation of Concern* - 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. *Server objects serialization problem* - 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 2010/1/4 Jan Ehrhardt jan.ehrha...@googlemail.com Hi Nathan, even, if I'm using Java on a server, I would prefer REST with JSON, since most of my server side projects are Spring based. My experience with GWT RPC and Spring is, that it's harder to integrate than doing some REST. With Spring 3.0 REST even becomes much more easier. A further point is the JPA serialization problem, I already told about. It will kill all the benefit of using GWT for serialization. A least I would expect, that in the Spring case REST can be much more productive than RPC. So I would add a fourth point to your list: (4) You're not using Spring (or Grails) on server side. Regards Jan Ehrhardt On Sun, Jan 3, 2010 at 10:34 PM, Nathan Wells nwwe...@gmail.com wrote: I don't agree about the separation of concerns factor with GWT-RPC. 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
Re: RPC vs HTTP requests
Sri,
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.
I've been using the following technique to use the JSON parsing in 2.0. I
don't see a specific example in the docs:
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
--
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
On Jan 4, 4:01 pm, Jeff Chimene jchim...@gmail.com wrote:
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.
I've been using the following technique to use the JSON parsing in 2.0. I
don't see a specific example in the docs:
Report.set(JSONParser.parse(response.getText()).isObject().getJavaScriptObj
ect());
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?
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();
--
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
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.) -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
hi all, 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 On Jan 5, 7:22 am, Thomas Broyer t.bro...@gmail.com wrote: 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.) -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
Sorry Pion, you are correct. Http supports syn and asyn calls. When you are using Http, you receive from the server or Xml file or a String (Key:value). It work fine for simple applications. But when you are building large and complex applications, you follow some design patterns (MVC for example) to help you. I think that using RPC is better in this case, you don't need to worry about the Http state, don't need to convert your Xml response, you just receive the java object that you create in the server, all information that you need with easy access. (sorry for the bad english) On Sat, Jan 2, 2010 at 11:56 PM, Yozons Support on Gmail yoz...@gmail.comwrote: 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
RPC means, that you can write Java Code for your browser, that invokes the methods of an server side object. It also provides a complete build in serialization for your Java objects. HTTP request means, that your doing a normal Ajax / HTTP request to an URL. Which solution is better, depends on what you're doing. If you're using Spring or Grails on your server, I would recommend to use HTTP with JSON as the exchange format. HTTP with JSON is supported by GWT through JavaScript overlays and build into Spring 3.0. If you're using PHP, Ruby or any other technology on the server, that is not Java Servlet based, I would also recommend HTTP. RPC is only great, if you're writing servlets yourself. GWT provides an out of the box servlet implementation for RPC, which can be used. Another bad thing on RPC is the serialization. Many people believe, that they can load there objects from a database through Hibernate or JPA and than, they can directly forward these objects to the Browser using RPC, but that isn't possible. The serialization isn't possible on objects created by persistence frameworks, so you'll need to convert them to a serializable transfer object, or you're writing your own persistence layer. 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). Regards Jan Ehrhardt On Sun, Jan 3, 2010 at 12:46 AM, Pion onlee2...@gmail.com wrote: Communicate with a Server - 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. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
Lucas, I don't agree with you. I would recommend to use HTTP, since you can use JSON instead of XML and JSON objects are directly available to your GWT app (JavaScript overlays). Furthermore in a RIA architecture (that's what GWT is developed for) you should have clear separation between your client (GWT app inside the Browser) and your server. this means, that your server should provide a well defined flexible and easy to use service interface, to call for data (includes writing of data). Such an interface can be done best by using a RESTful architecture. So you'll get two benefits, your GWT client can call the interface using JSON as exchange format and other clients can do the same with XML, if they prefer. Most frameworks support JSON and XML for REST out of the box, so you can just place a format property in the HTTP request. Another point is, that RPC makes it much easier to mix client and server code. This means, that your separation of what belongs to the client and what belongs to the server won't be as clear and independent of each other. REST instead will decouple both very well. So your client depends on a RESTful interface but not on server side technology. You can even switch the server to a complete new .NET implementation as long as it provides the same RESTful API. Regards Jan Ehrhardt On Sun, Jan 3, 2010 at 12:12 PM, Lucas Vargas Freitas Ventura lucasvfvent...@gmail.com wrote: Sorry Pion, you are correct. Http supports syn and asyn calls. When you are using Http, you receive from the server or Xml file or a String (Key:value). It work fine for simple applications. But when you are building large and complex applications, you follow some design patterns (MVC for example) to help you. I think that using RPC is better in this case, you don't need to worry about the Http state, don't need to convert your Xml response, you just receive the java object that you create in the server, all information that you need with easy access. (sorry for the bad english) On Sat, Jan 2, 2010 at 11:56 PM, Yozons Support on Gmail yoz...@gmail.com wrote: 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
For me, one of the most important points is that I didn't want to have 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... - 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
Hi Jan: 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 On Sun, 2010-01-03 at 12:32 +0100, Jan Ehrhardt wrote: Lucas, I don't agree with you. I would recommend to use HTTP, since you can use JSON instead of XML and JSON objects are directly available to your GWT app (JavaScript overlays). Furthermore in a RIA architecture (that's what GWT is developed for) you should have clear separation between your client (GWT app inside the Browser) and your server. this means, that your server should provide a well defined flexible and easy to use service interface, to call for data (includes writing of data). Such an interface can be done best by using a RESTful architecture. So you'll get two benefits, your GWT client can call the interface using JSON as exchange format and other clients can do the same with XML, if they prefer. Most frameworks support JSON and XML for REST out of the box, so you can just place a format property in the HTTP request. Another point is, that RPC makes it much easier to mix client and server code. This means, that your separation of what belongs to the client and what belongs to the server won't be as clear and independent of each other. REST instead will decouple both very well. So your client depends on a RESTful interface but not on server side technology. You can even switch the server to a complete new .NET implementation as long as it provides the same RESTful API. Regards Jan Ehrhardt On Sun, Jan 3, 2010 at 12:12 PM, Lucas Vargas Freitas Ventura lucasvfvent...@gmail.com wrote: Sorry Pion, you are correct. Http supports syn and asyn calls. When you are using Http, you receive from the server or Xml file or a String (Key:value). It work fine for simple applications. But when you are building large and complex applications, you follow some design patterns (MVC for example) to help you. I think that using RPC is better in this case, you don't need to worry about the Http state, don't need to convert your Xml response, you just receive the java object that you create in the server, all information that you need with easy access. (sorry for the bad english) On Sat, Jan 2, 2010 at 11:56 PM, Yozons Support on Gmail yoz...@gmail.com wrote: 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-web- tool...@googlegroups.com. To unsubscribe from this group, send email to google- web-toolkit+unsubscr...@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- tool...@googlegroups.com. To unsubscribe from this group, send email to google-web- toolkit+unsubscr...@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- tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You
Re: RPC vs HTTP requests
I don't agree about the separation of concerns factor with GWT-RPC. 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- 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 On Sun, 2010-01-03 at 12:32 +0100, Jan Ehrhardt wrote: Lucas, I don't agree with you. I would recommend to use HTTP, since you can use JSON instead of XML and JSON objects are directly available to your GWT app (JavaScript overlays). Furthermore in a RIA architecture (that's what GWT is developed for) you should have clear separation between your client (GWT app inside the Browser) and your server. this means, that your server should provide a well defined flexible and easy to use service interface, to call for data (includes writing of data). Such an interface can be done best by using a RESTful architecture. So you'll get two benefits, your GWT client can call the interface using JSON as exchange format and other clients can do the same with XML, if they prefer. Most frameworks support JSON and XML for REST out of the box, so you can just place a format property in the HTTP request. Another point is, that RPC makes it much easier to mix client and server code. This means, that your separation of what belongs to the client and what belongs to the server won't be as clear and independent of each other. REST instead will decouple both very well. So your client depends on a RESTful interface but not on server side technology. You can even switch the server to a complete new .NET implementation as long as it provides the same RESTful API. Regards Jan Ehrhardt On Sun, Jan 3, 2010 at 12:12 PM, Lucas Vargas Freitas Ventura lucasvfvent...@gmail.com wrote: Sorry Pion, you are correct. Http supports syn and asyn calls. When you are using Http, you receive from the server or Xml file or a String (Key:value). It work fine for simple applications. But when you are building large and complex applications, you follow some design patterns (MVC for example) to help you. I think that using RPC is better in this case, you don't need to worry about the Http state, don't need to convert your Xml response, you just receive the java object that you create in the server, all information that you need with easy access. (sorry for the bad english) On Sat, Jan 2, 2010 at 11:56 PM, Yozons Support on Gmail yoz...@gmail.com wrote: 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-web- tool...@googlegroups.com. To unsubscribe from this group, send email to google- web-toolkit+unsubscr...@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
Re: RPC vs HTTP requests
Hi Nathan, even, if I'm using Java on a server, I would prefer REST with JSON, since most of my server side projects are Spring based. My experience with GWT RPC and Spring is, that it's harder to integrate than doing some REST. With Spring 3.0 REST even becomes much more easier. A further point is the JPA serialization problem, I already told about. It will kill all the benefit of using GWT for serialization. A least I would expect, that in the Spring case REST can be much more productive than RPC. So I would add a fourth point to your list: (4) You're not using Spring (or Grails) on server side. Regards Jan Ehrhardt On Sun, Jan 3, 2010 at 10:34 PM, Nathan Wells nwwe...@gmail.com wrote: I don't agree about the separation of concerns factor with GWT-RPC. 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- 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 On Sun, 2010-01-03 at 12:32 +0100, Jan Ehrhardt wrote: Lucas, I don't agree with you. I would recommend to use HTTP, since you can use JSON instead of XML and JSON objects are directly available to your GWT app (JavaScript overlays). Furthermore in a RIA architecture (that's what GWT is developed for) you should have clear separation between your client (GWT app inside the Browser) and your server. this means, that your server should provide a well defined flexible and easy to use service interface, to call for data (includes writing of data). Such an interface can be done best by using a RESTful architecture. So you'll get two benefits, your GWT client can call the interface using JSON as exchange format and other clients can do the same with XML, if they prefer. Most frameworks support JSON and XML for REST out of the box, so you can just place a format property in the HTTP request. Another point is, that RPC makes it much easier to mix client and server code. This means, that your separation of what belongs to the client and what belongs to the server won't be as clear and independent of each other. REST instead will decouple both very well. So your client depends on a RESTful interface but not on server side technology. You can even switch the server to a complete new .NET implementation as long as it provides the same RESTful API. Regards Jan Ehrhardt On Sun, Jan 3, 2010 at 12:12 PM, Lucas Vargas Freitas Ventura lucasvfvent...@gmail.com wrote: Sorry Pion, you are correct. Http supports syn and asyn calls. When you are using Http, you receive from the server or Xml file or a String (Key:value). It work fine for simple applications. But when you are building large and complex applications, you follow some design patterns (MVC for example) to help you. I think that using RPC is better in this case, you don't need to worry about the Http state, don't need to convert your Xml response, you just receive the java object that you create in the server, all information that you need with easy access. (sorry for the bad english) On Sat, Jan 2, 2010 at 11:56 PM, Yozons Support on Gmail yoz...@gmail.com wrote: 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
Re: RPC vs HTTP requests
At the expense of repeating a few points already mentioned, here's my summary - * Server Platform* 1. If you are using a non-java platform on server side, GWT RPC is not an option. 2. 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. 3. If you are already using a json - java - json library, you are perhaps already invested in REST, and so should stick to that approach. *Reusability of Services* - If you want to reuse services with other non-GWT projects, REST with JSON XML is the only option. 1. *Ease of Use / Abstraction* - 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. *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. - 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. *Separation of Concern* - 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. *Server objects serialization problem* - 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 2010/1/4 Jan Ehrhardt jan.ehrha...@googlemail.com Hi Nathan, even, if I'm using Java on a server, I would prefer REST with JSON, since most of my server side projects are Spring based. My experience with GWT RPC and Spring is, that it's harder to integrate than doing some REST. With Spring 3.0 REST even becomes much more easier. A further point is the JPA serialization problem, I already told about. It will kill all the benefit of using GWT for serialization. A least I would expect, that in the Spring case REST can be much more productive than RPC. So I would add a fourth point to your list: (4) You're not using Spring (or Grails) on server side. Regards Jan Ehrhardt On Sun, Jan 3, 2010 at 10:34 PM, Nathan Wells nwwe...@gmail.com wrote: I don't agree about the separation of concerns factor with GWT-RPC. 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- toolkit.googlecode.com/svn/javadoc/2.0/index.html in GWT trunk and
RPC vs HTTP requests
Communicate with a Server - 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. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
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/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. -- 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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
http://code.google.com/webtoolkit/doc/latest/DevGuideServerCommunication.html#DevGuideHttpRequests 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RPC vs HTTP requests
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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
