We Keep Coding

Understanding REST with a GWT example

I am a newbie to RESTful services.
In my attempt to gain practical exp. with REST in GWT I am trying to create a simple GWT web-app.
The boiler plate code generated by GWT plugin in Eclipse is a nice working example but uses RPC mechanism to interact with backend. I would like to modify this app to use RESTful services.
So, far I have figured that I can use RESTEasy server and restyGWT to get this done. Also a stackoverflow answer says that using Errai JAX-RS, building REST clients is as easy as implementing RPC, but this all seems too abstract to me.
Am I looking at the right tools for the job?
I am looking forward to any suggestion on how to proceed. Any sample code would be great.
Regrds,Mohit

I would recomend restyGWT from experience or the native GWT request factory. RestyGWT is very easy to setup and configure. You simply create an interface that mirrors your server implementation with the same annotations for #GET, #PUT, #PATH etc. The only difference is that you add a final argument to your interface implementation for a MethodCallback with the return. The only downside to this RestyGWT in my opinion is that it uses the GWT RPC for the implementation. This has caused some issues with me in the past when trying to add non white listed classes to the domain objects. You will run into issues where a class that is included is not serializable and cannot be transported to the browser client. It is my opinion to leave your rest services as they are and use requestfactory for the serialization and transport. RequestFactory does not suffer from the same white-listed class problems. It essentially uses a proxy interface on the client side that mirrors your server domain object implementation. RequestFactory can coexist with your back end rest services and use the same code as the Resource classes for retrieving the server side objects.
Here are the link to the gwt requestfactory documentation
http://www.gwtproject.org/doc/latest/DevGuideRequestFactory.html
Here is restygwt's pizza example that is what I used to get started
http://restygwt.fusesource.org/documentation/restygwt-user-guide.html

SoapUI vs Java Web Service Client

If a SOAP web service is working well via SoapUI (producing the correct SOAP responses), while building a web service client in Java using different APIs/frameworks to call this web service is facing different issues, is it safe to consider this web service stable and the issues are from the consumer side?
I'm asking a generic question in here, I have already asked a detailed one which is probably too long to read. I'm interested in the concept more than my actual implementation, so if you can answer my question without referring to my longer post, please do.
UPDATE:
I have realized that even if the WSDL is WS-I compliant and it's functioning correctly via SoapUI, this is still not enough to conclude that the web service is not broken. As #jtahlborn said, SoapUI is very tolerant to broken web services, and it could easily trick you to believe your web service is working fine, which is what happened in my case.
I'm constructing the SOAP response in the ESB and my issue was that I used a namespace that was defined in the WSDL but not in the schema. SoapUI received the response and showed it to me (with the wrong namespace); this issue could have been avoided if I turned on the response validation option.
It's also noteworthy to mention that in the Java web service client I created to test my web service, the response could not be loaded into the output object (a NullPointerException error showed up when I tried to access the output object), this was due to the namespace issue and it started working correctly once I fixed the namespace.

SoapUI is a fantastic product. one of the things which makes it a great product, however, is that it is very tolerant of poorly defined webservices. in our product, we deal with lots of webservices, and a frequent comment on an issue in our product is "it works fine in SoapUI". we have learned the hard way that SoapUI will tolerate all kinds of broken webservices. so, in summary, working with SoapUI is not a proof that your webservice is well-defined.

There are WS-I testing tools to check your web service for conformance to the Web Services Interoperability profiles. If your service adheres to the WS-I basic profile, and SoapUI can call it, the issues are definitely on the consumer side.
EDIT: well, or in between the both...
SoapUI can check your wsdl for WS-I compliance, see http://www.soapui.org/SOAP-and-WSDL/working-with-wsdls.html.

It's most likely that the consumer (client) is buggy... If the client is generated using wsdl2java it's a big chance to have bugs in it... and if you are using some special functionalities that are valid (conforming w3c) then don't be surprised... the generated clients sometimes do this... even some libraries used to generate java classes or libraries to generate the webservices are full of bugs...
A lot of things are not supported by known and frequently used libraries... (I don't want to give names -- but wsdl4java is not perfect)..
If you are using security or something ... higher chances to have bugs on both server and client side :)
maybe if you tell us what is the problem we can help you...

Is GWT compatible with app-engine's multitenancy support

Just looking for confirmation that the GWT RPCs play well with app-engine's new multi-tenancy support based on name-spaces.

The two technologies are very compatiable. I have been using them together for a long time. In fact there are some syntatic sugar that makes them easy to be used together, such are RPC calls. Plus now your server and client code are in the same language. Using eclipse and the setup that google developed for eclipse and GWT/AppEngine I have all the code in one project with a client, server and shared code. The client and Shared code gets compiled with GWT and the server and shared code get compiled for AppEngine.
I hope this helps.
https://developers.google.com/web-toolkit/doc/1.6/tutorial/appengine
Michael

You can try to use multi-tenancy in your GWT-RPC, but it will not be just configuration. You can use per-user multi-tenancy setting NameSpace using filter, but do not forget that if you start AsyncTasks from gwt-rpc calls you will not have valid user in tasks requests so you will need to figure out how to choose namespace in tasks.

As long as your server-side implementations correctly handle the multi-tenancy, you'll be fine.
There is no additional load to using multi-tenancy with GWT-RPC, but there is additional load using multi-tenancy and you won't be able to avoid that with GWT-RPC.

Best architecture for applications in GWT

I'm starting to study GWT now, and have a very general question, I could maybe teach myself with a little more experience, but I don't want to start it wrong, so I decided to ask you.
I always develop using JSF, having separate packages for beans, controllers and managedbeans.
However, as the GWT uses RPC, I will not have managedbeans, right?
So, GWT automatically handles user session for me, or do I have to do it myself?
What is the best package structure for the project?
It is best to use RPC, or create a webservice and access the webservice in GWT?
It's hard to host the application on a tomcat server?
Is there a test saying which server is faster for GWT?
Thank you.

However, as the GWT uses RPC, I will not have managedbeans, right?
True, GWT RPC uses POJOs.
So, GWT automatically handles user session for me, or do I have to do it myself?
GWT is pure AJAX APP - client code (normally) runs in one browser window (similar to gmail) and does not reload the web page. This means that the application state is always there - no need for sessions (as a means of saving state). You still might need sessions for user authentication, but this is usually handled by servlet container.
What is the best package structure for the project?
Three packages: client, server and shared. Client for GWT client code, server for server (also RPC) code and shared for POJOs that are used by both client and server.
It is best to use RPC, or create a webservice and access the webservice in GWT?
Go with GWT-RPC or (better, newer) with RequestFactory.
It's hard to host the application on a tomcat server?
It's straightforward: GWT client code is compiled to JS/html and is hosted as any static content. RPC server code is just Servlets - normal web.xml registration.
Is there a test saying which server is faster for GWT?
No clue, but IMHO does not matter, because most of the latency will come from database and network.

Also have a look at http://code.google.com/p/gwt-platform/
This framework is really great and follow all suggested best practices(e.g. MVP) by google and give you as well great support for gin, gwt dispatcher, website crawling, history with tokens, code splitting via gwt async etc.
If you want to set up a good project structure try to use the maven gwt plugin(http://mojo.codehaus.org/gwt-maven-plugin/) it helps you a lot with setting up an initial structure and manage your build process.

Is it possible to call a GWT servlet from native Java?

I have a GWT application, with a Native Java backend, and a compiled Javascript front-end (as usual).
My GWT service should also be accessible from other clients, including a java applet. Initially my idea was to double the GWT service as a SOAP service, and use a soap client from the applet to access the GWT service, but I am wondering if it might be possible to use the built-in GWT client infrastructure to call the server from Java.

The problem with this approach is serializing the request and deserialize the response so as to be compatible with the GWT service.
One solution is to use GWT SyncProxy:
http://code.google.com/p/gwt-syncproxy/
which is explained here:
(dead) http://www.gdevelop.com/blog/2010/01/testing-gwt-rpc-services/
(Wayback Archive) http://wayback.archive.org/web/20130107141210/http://www.gdevelop.com/blog/2010/01/testing-gwt-rpc-services/
You can use it directly or, since they provide the source, you take a peek to see how they serialize the request and deserialize the response.

Another approach is to use Restlet to provide the services and then convert your GWT client to make REST calls. The Restlet people provide a GWT library to facilitate this.
http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/144-restlet.html
They provide an example of calling the REST service via Restlet from different clients, including GWT client, Java SE, and Android:
http://wiki.restlet.org/docs_2.0/13-restlet/21-restlet/318-restlet/303-restlet.html
Edit:
I only know RESTlet from evaluating it last year for my GWT project. I'm no expert and I didn't end up using it, but this is no reflection, good or bad, on RESTlet.
OP asks:
What would be the advantage of using the Restlet framework over JAX-RS ?
Essentially, JAX-RS is an just API (like JDBC) - you still need to pick an implementation or use the reference implementation Jersey. RESTLet has an extension for supporting JAX-RS API.
http://www.restlet.org/about/faq#07
7. What is the link between Restlet and JAX-RS (JSR-311)?
...
To summarize, both APIs have very different designs but are potentially complementary. The good news is that Jérôme Louvel (Restlet's creator) is an active member of the JSR-311 Expert Group and that an implementation of the JAX-RS API was made on top of the Restlet API. This "JAX-RS extension for Restlet" was developed by Stephan Koops in the context of his Master thesis and is one of the most advanced implementations available. For more documentation on this extension, please refer to this page.
OP asks:
Is it possible to use Tomcat / web.xml infrastructure instead of org.reslet.server
http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/312-restlet.html
This edition is aimed for development and deployment of Restlet applications inside Java EE application server, or more precisely inside Servlet containers such as Apache Tomcat.