Posted by Jerome Louvel in : GWT, NIO, OData, Restlet Releases
- no comment
We are still on track for the 2.1 RC1 release in September, but so many enhancements and bug fixes were added since 2.1 M5 that we thought it would be useful to many users to have this intermediary milestone.
First, the 2.0.9 version fixes 10 issues on the stable branch including:
- Inappropriate warning message about child contexts
- IO flushing issue that could create troubles with writer based representations such as JsonRepresentation
- Conversion of representations to instances of primitive type using the default converter
- Handling of binary data in OData extension
- Default converter took precedence over specialized converters when converting incoming representations
- Lack of warning message when an unexpected error happen during the invocation of an asynchronous callback
Those fixes are of course also available in the new 2.1 release.
In addition, version 2.1 Milestone 6 contains several major enhancements and new features summarized below.
- Improved Restlet annotation value syntax to support alternate variants using ‘|’ and combination of several metadata for a single variant using ‘+’ separator. Also, all metadata are now supported, not just media types. In addition, support for URI query constraints was added to allow annotations such as @Get(“form:json?light”) or @Get(“?level=2″), working on both client and server side
- Added org.restlet.ext.html extension supporting writing HTML forms in either URL encoded format or multipart form data, with the same FormDataSet class. Parsing of multipart form data isn’t supported yet.
- Added CookieAuthenticator in the org.restlet.ext.crypto extension to provide customizable and secure authentication via cookies, in a way that is as compatible as possible with HTTP challenge based authentication
- Added ConnegService providing a way to control the content negotiation behavior at the application level. It offers two modes: strict and flexible (default) but additional algorithms can be implemented.
- Added org.restlet.ext.emf extension supporting the conversion between EMF generated beans and XML or XMI representations. It can also automatically write simple HTML representations for navigating your web API.
- Added HTTPS server connector based on the internal non-blocking NIO connector. Co-developed with NetDev.
- Many minor enhancement to the Restlet API for conveniency purpose such as a new Representation.append(Appendable) method.
API breaking change
When retrieving or updating the raw headers in the Request or Response attributes, the type should now be Series<Header> instead of Series<Parameter>
- Bryan Hunt
- Cyril Lakech
- David Bordoley
- David Hamilton
- Glenn Bruns
- Jean-Pascal Boignard
- Jeroen Goubert
- John Logdson
- Konstantin Pelykh
- Martin Svensson
- Nikhil Purushe
- Ray Waldin
- Remi Dewitte
- Scott S. McCoy
- Tim Peierls
- Thomas Eskenazi
Thanks to all others who helped us in various ways for this milestone.
Posted by Jerome Louvel in : Android, Ecosystem, GAE, Google, GWT, Microsoft, REST, Restlet, Restlet General
- no comment
The Web is taking multiple shapes with the Mobile Web, Cloud Computing and RIA being hot topics recently. If you follow this blog frequently, you are certainly aware that the Restlet Framework, the first RESTful web framework for Java developers, is available in five consistent editions since version 2.0 M4. Each edition targets a special development environment:
- Google Web Toolkit (GWT) for AJAX applications deployed in desktop browsers, without any plugin required
- Google App Engine (GAE/J) for deployment on Google’s cloud computing infrastructure
- Android for deployment on compatible smartphones
- Java SE for standalone deployments in regular Java Virtual Machines
- Java EE for deployment in Servlet engines
Each edition is offering the same Restlet Framework, with restrictions and adjustments based on the target environment. For example, the GWT edition only supports the client-side usage of Restlet, while the GAE edition only provides compatible extensions and ensures that we don’t break the security sandbox or use unsupported JRE classes.
As a result, you can easily develop a unified Restlet application with a server-side deployed in GAE, a client version available for Android smartphones and another available for desktop browsers with GWT, fully leveraging the most innovative technologies available from Google for Java developers.
You might wonder what exact value does Restlet brings in the middle of those technologies? The Restlet Framework is all about REST, supporting advanced HTTP features such as content negotiation, caching and conditional processing, allowing for the same URI-addressable resource to expose various representations. Each representation renders the same information in various languages or formats such as JSON, XML or anything else that makes sense for your clients such as binary pictures.
Supporting content negotiation allows your Restlet cloud server to expose the same resources to all its clients, including an Android smartphone client, a GWT desktop client, a Flex client, a programmatic Java SE robot or a basic HTML browser. One Java API and one unified code base gets you covered in all those scenarios, even if you need to serve static files: a Restlet Application truly merges the notion of Web Site, Web App and Web Service!
So, using Restlet as a cloud server gets you much further than a regular Servlet application. Usually, you would use GWT-RPC to communicate between your GWT client and your GAE back-end, and the low-level HTTP client provided by Android to communicate with your GAE custom Servlets. Obviously, the result wouldn’t be very RESTful as GWT-RPC is introducing some strong coupling. You could use the low-level HTTP client provided by GWT as well, but then you would loose the big benefit of using Java proxies in GWT, with transparent serialization of parameters and result object.
This is where the Restlet Framework comes to rescue! For GWT, we provide both a high-level HTTP client, removing the need to manually parse and format HTTP headers thanks to its Restlet API but also a proxy generation mechanism based on GWT deferred binding very similar to GWT-RPC but truly RESTful! Migration of existing GWT-RPC code is straightforward as we also support GWT-RPC AsyncCallback interface in addition to our equivalent Result interface. For our serialization format, we reused the one of GWT-RPC, a special JSON variant, therefore it is fully featured and as robust as GWT-RPC ! In your Restlet cloud server, you just need to add our server-side GWT extension to transparently support this serialization format, thanks to content negotiation.
If you are a Google fan, you should be happily developing with the recent GWT 2.0, Android 2.0 and GAE 1.3.0 releases and the RESTful solution described above should gives you a big smile and to get started, we have written a complete tutorial, with full source code, illustrating a unified Restlet application for GAE, GWT and Android.
But even in this scenario, you wouldn’t be restricted to Google technologies, you could chose to support alternative clients such as regular HTML browsers, Flex or Silverlight clients, or any other HTTP client. On the server-side, you could take the same Restlet application and deploy it locally, or on Amazon EC2 or Microsoft Azure, thanks to our Restlet editions for Java SE and Java EE which can be installed on those major cloud platforms!
In the end, the Restlet Framework offers you, for free, the first comprehensive RESTful middleware for Google technologies and beyond! As a last word, I would like to thank again my friend Didier Girard, for sharing his insights that led us to this post (and a lot of work!)
Posted by Jerome Louvel in : Android, GWT, Restlet, Restlet General
- no comment
Our vision is that the Web is becoming ubiquitous and that REST, as the architecture style of the Web, helps you leverage all HTTP features. Restlet, our open source REST framework, is already available on regular computers based on Java SE/EE, in Web browers with our GWT edition and even in the cloud with a new Google AppEngine edition. But, we are still missing the Mobile Web!
With the commodification of smartphones started by the Palm Treo and pushed further by the Apple iPhone, more and more mobile users will have a usable access to the Web from their phone. So far, developers have been stuck with proprietary platforms and where lacking the productivity and portability common in the Java world. But here comes Android!
Android is an open source mobile operating system initiated by Google but now managed by the Open Handset Alliance. This consortium includes prestigious constructors such as HTC, Motorola, Samsung or Sony Ericsson and larger carriers such as Sprint, T-Mobile or Vodaphone. Needless to say that Android has gained a lot of traction recently.
Technically speaking, Android is built on a customized Linux kernel, libraries such as WebKit for the Web browser and an extensible Application Framework developed in the Java language but running on a special Dalvik virtual machine (see a complete overview here). All the built-in applications are written in Java and can accessed or customized via an Android API.
Preparing for an imminent launch of the Android-powered HTC Magic phone in France (also known as the “G2″), the mobile operator SFR, one of the third largest in France, has announced a contest for the best Android application. We thought it was a perfect opportunity to port the Restlet framework to another exciting environment and applied as a “Restlet+FOAF” project.
With some adjustments (see technical details), we were able to port Restlet on Android, with both the client-side and the server-side HTTP connectors! To show the potential of Restlet on Android, we decided to go further and develop a simple extension to the Contacts applications that would retrieve the FOAF (Friend-Of-A-Friend) profile of your contacts, show their friends and let you add some as new local contacts. The source code of this sample application is available and documented in the Restlet User Guide.
With the help of Manning’s “Unlocking Android” book, we also discovered Android’s Intent/Service design pattern, which is quite similar to Eclipse’s plug-ins. This is a powerful way to extend Android applications and share common features. In our case, we developed a FOAF Service that can be reused by other Android applications, without tight coupling on our code.
Finally, with the growing number of Restlet editions, we felt the need to put in place an automatic porting process to keep the code changes synchronized. This effort is underway but you can already read its specifications in our developers wiki. All those new features are available in recent Restlet snapshots. Enjoy!
Posted by Jerome Louvel in : GWT, Restlet General, User interface
- no comment
Google Web Toolkit is a very successful technology that brings Java right inside Web browsers. It could be compared to traditional Applets but without requiring any extra plugin and with a more natural integration with the browser artifacts.
Now, how can you leverage REST in GWT? By default, they propose an opaque GWT-RPC mechanism that is closer to SOAP than to REST. It gives a feeling of transparent distribution but actually introduces tight coupling between client and server code and prevents you from leveraging existing RESTful back-ends. There is an HTTP request builder class that you can use, but it requires knowledge of lower HTTP levels like the exact headers syntax.
Wouldn’t it be nice to use the Restlet API instead, which provides a higher level mapping of HTTP semantics to a clean Java API ? Thanks to the support for generics added in GWT 1.5, we were able to achieve this port with reduced efforts and limited troubles. We had to get rid of the server-side features that don’t make sense in a browser, and of the APIs like NIO and logging that aren’t emulated by GWT. The major impact was the adaptation of the API to the asynchronous communication imposed by AJAX and GWT.
The port, named “Restlet edition for GWT”, is available since Restlet 1.1 and its usage is documented in our Wiki. There is a discussion comparing the GWT-RPC and Restlet edition for GWT architectures and much more! The testing, most of the documentation as well as the back-end integration (see the server-side GWT extension) was contributed by Rob Heittman. I would like to thank him as well for the numerous design discussions while working on this port.
Rob Heittman is Chief Technology Officer at Solertium. Using prototypes of the Restlet edition for GWT, Solertium has been building large enterprise applications with Restlet and GWT for the past year, for worldwide customers like IUCN and Conservation International. “I love GWT, but I prefer RESTful web services to RPC,” says Rob. “GWT backed by Restlet has been great for us. Now, GWT 1.5 and the new Restlet edition for GWT will make our client-side code as simple and elegant as our server code.”
Finally, if you want to follow the latest news about GWT, I recommend the onGWT blog. It is maintained by Didier Girard, a good friend who introduced me to the joys of GWT!