Understanding REST with a GWT example - java

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

Related

Can GWTP Rest Dispatch be used with REST Spring server backend?

I've started to use GWTP framework. And I've noticed that it has his own implementation of Rest comunication. I've used to use GWT with RestyGWT And Spring server.
Now I wonder- can I use GWTP Rest Dispatch with Spring server?
Or should I stick with RestyGWT (which is not a part from GWTP).
I haven't found a word about it in official documentation of GWTP. And the example given have in shared package rest service interface, which is implemented on server side. Please help.
You can definitely use Rest Dispatch with whatever backend you like. Take a look at this tutorial if you'd like more information on how to setup Rest Dispatch. This tutorial was also tested using the Python webapp2 web framework as backend.
GWTP REST Dispatch just calls REST URLs, so it doesn't care which implementation is behind the URL, as long as it's reachable by it and returns a proper response. So yes, you are totally fine to use Spring MVC, JAX-RS or anything else for your backend.

What does RESTful web service actually does that HTTP programming doesn't? What is the main use of RESTful WS

I know RESTful WS is an architecture all together, which is a new way of implementing Web Services over old fashioned JAX-RPC's.
In RESTful, we use #GET, #POST, etc to manage calls/develop resources. Same can be achieved using HTTP programming (both are stateless too).
But what are other core main uses or need for bringing/implementing RESTful? As everything we do in it, can be done using HTTP programming (in which we use same methods)?
The question is comparing different things. HTTP is a protocol, while REST is an architectural style. This is like asking what a house does that a brick doesn't. It doesn't make sense. HTTP can be a building block of a REST application.
REST is not about HTTP or any particular protocol. REST is about applying the successful design decisions of the Web itself to software development. The problem is terminology. 99.9% of the so called REST applications around the internet aren't really RESTful, because REST became a buzzword to refer to any HTTP API that isn't SOAP. Some REST advocates gave up on fighting for the proper usage of the term and now refer to REST applications as Hypermedia.
Like the Web, REST is intended for software development in the scale of decades. REST makes it easier to evolve your application without breaking clients. Think about how today you can still access websites that were created decades ago, and almost everything still works fine. If you're creating software that has long-term objectives in the scale of several years, then maybe REST is adequate for you. If that's not what you really need, then getting REST right is not important. Just use whatever works for you, and at this point I think nobody cares anymore if you call it REST.
The question is not "REST versus HTTP-Programing". REST is a higher concept on how to to create distributed web applications. HTTP is a concrete technology . REST defines some constraints which are considered as good practice.
HTTP is just a technology which is well suited to implement REST-Style services:
Addressability => in HTTP every resource can be addressed through a unique identifier (URI)
multiple Representations => every resource can have multiple representations (JSON, XML) - a HTTP-Request for instance can 'ask' for the right representation (via headers)
Common Interface => Instead of creating an application specific interface (Methodnames in SOAP) HTTP already provides an Interface: GET, PUT, POST, DELETE ...)
Stateless => HTTP-Requests are stateless by design
Hypermedia => The application state (client) is driven by examining the links contained in the representations
HTTP is a transfer protocol.
RESTful is a group of principles.
Basically a RESTful web service is a particular HTTP application that follow the following principles:
client server
stateless
cacheable
layered

Is it possible to consume an EJB 3 Web Service form a Java client without first generating client stubs/proxies?

In most tutorials that I have seen so far people are using wsconsume or something like that to create classes that clients can use to access an EJB 3 Web Service.
Is this the only possible option? As my EJB's interface is annotated with WebMethod, WebParam, etc. isn't it possible to create a dynamic proxy or use runtime bytecode enhancement to create the proxies, etc. on the fly? E.g.:
MyWebService webService = WebServiceEnhance.getWebService(MyWebService.class);
webService.webMethod("foo");
A link to good reference material is also highly appreciated.
One way is to deal with pure XML request/response. You can trap sample request/response for the web service you want to consume using either SoapUI or Fiddler and then use these samples as templates within your client.

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.

Combing Metro and Jersey

I've been at this for a little while and my mind has gone to mush.
I'm wondering if anyone can help me out here. I'm trying to make a Java Web Service (using its own HTTP server and not something like tomcat), that supports Metro and Jersey. This way a client can connect to the web service anyway they want whether it is SOAP or REST.
I've got the metro part down so it can support Doc/Lit wsdls and RPC/lit wsdls but I've having some difficultly understanding the Jersey part so it will support REST/xml and REST/json
Also the idea is that there would be one class where all the endpoint methods are written in and other classes would extend it.
Has anyone used these two combined before? Can you point me the direction of a decent article or do you have an example yourself?
Thanks
Metro is a implementaion of JAX-WS used mainly for WSDL/SOAP based webservices.
Jesery is a implementation of JAX-RS used maily for Restful based webservices.
I have used both in the same project but for different purposes. You can also use apache httpclient for restful services, but jersery provides lot of useful annotations for converting to json, xml etc. Hope it helps.
I am a bit confused about what you mean when you say you want to support Jersey. Jersey is an implementation of JAX-RS (JSR-311). Do you mean you want to support JAX-RS?

Categories