About
Disclaimer: the views expressed on this site are mine alone and do not necessarily reflect the views of my employer or its affiliated entities.
rest
If your familiar with GWT RPC, then you you know that it’s it’s provides a very nice client side framework for doing AJAX requests against Java Servlets. The sad part is that it uses a binary protocol. That protocol is not easily understood by other languages or frameworks.
Counter that with latest AJAX rage, RESTful services with a JSON or XML representation of the data. The nice thing about using JSON with REST services is that clients and servers can easily be built it any language. Wouldn’t it be nice if you use JSON RESTful services from GWT with the ease of GWT RPC?
That’s exactly the reason I started hacking on RestyGWT. It uses a very similar development model as GWT RPC. You create a service interface who’s implementation is code generated via Deferred Binding when your GWT module is built. The developer maps the interface methods to RESTful HTTP requests using the excelent JAX-RS annotations. Just like in GWT RPC, the interface must be ‘asynchronous’. You must use callback method arguments to get the request results. But unlike GWT RPC, the data sent and received will be JSON encoded. RestyGWT will automatically code generate JSON encoders and decoders for any classes sent or received from the rest service.
For more details see the Git Hub home page at: http://github.com/chirino/resty-gwt
As of this point, RestyGWT only implements the most basic JAX-RS annotations and provides a very simple JSON encoding scheme. Despite that, the project is already extremely useful. I would love here what folks think about it.
I’m one of those guys that thinks that REST is great technology. Sure, REST is does not do everything that SOAP can do, but I think that REST is built to be SIMPLE, something that SOAP and it’s WS-* buddies forgot about.
What we are missing is a good standard way to map REST to the simple POJO programming model that most of the Java industry has been quickly adopting. Seems SeXFire Dan has good start on a way of doing that!
Dan if you read this, I would make it even simpler if by default the method names for a service are determined by convention. For example, for a given XService, the methods:
deleteX(…): is automatically mapped to a HttpMethod.DELETE
addX(…): is automatically mapped to HttpMethod.POST
updateX(…): is automatically mapped to a HttpMethod.PUT