Hi Matt, In addition to what was already said, I would add that a strong advantage of Restlet is its adaptability to various environments: - standalone with light and fast apps - embedded in JEE/Servlet containers for integration into larger existing ecosystems - Restlet-GWT port for rich browser client apps - OSGi containers (Eclipse Equinox, Apache Felix, Spring dm Server) - Spring and Guice IoC containers - Groovy-Restlet module for scripting
We were also able to make it work inside a JAIN/SLEE containers and have plans for an Android port for usage in mobile phones. Otherwise, I've entered a RFE for: "Support bean binding and validation" http://restlet.tigris.org/issues/show_bug.cgi?id=713 Regarding the scalability, we have a benchmark *in progress* that is available at this address: http://www.restlet.org/documentation/1.1/benchmark Note that that recent snapshots work fine with Grizzly as opposed to when the last bench was done. In conclusion, it scales really well and you can even switch the HTTP connector implementation to never get stuck by a potential issue in one of them. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -----Message d'origine----- De : [email protected] [mailto:[email protected]] Envoye : jeudi 22 janvier 2009 19:02 A : [email protected] Objet : Restlet vs other 'rest' frameworks questions/views Hi There This is more of a holistic ?? on restlet. I have been using it for months and now we have a 'restful' project at work. I.e. our first one. I am pushing hard for restlet but we also have some people who want to try jersey or even write some layer on top of spring mvc or look at struts 2... Here are my requirements. 1) All our responses will have some 'envelope' in terms of the response data. I.e. if we serve xml all responses would have a simliar format. e.g. <company> <tos> TERM OF SERVICE FOR ALL RESPONSES </tos> <error codes> Here would be error codes like 'param not found' <error codes> <response> ....// concrete data here based on java object type.... </response> </company> I did this quite easily by creating a 'template' resources that handles a lot of the uniform plumbing (error catching, creating response object) and subclassed with concrete resources that would return the 'real data' via some template method. This worked lovely. I also used spring which was great as I could have state in my resources... Another desire is to parse the return type based on some uri param. i.e. //mywsite/cars/123 -> return xml default //mywsite/cars/123?format=txt -> return txt if supported by resource.. and NOT //mywsite/cars/123.xml Once again this shined with the great tunnel service.. I also used jibx on my domain models and once again used the Jibx Representation and it shined. The one down side my co-workers see is the lack of binding url params to some kind of bean element (like Struts, spring mvc etc) and that we would have to write our own. They are also curious about the 'scale' of restlet (if for example as a stand alone app) and the number of concurrent requests we can take at any given time. I will poke around at the code too see if i can dig up anything. Anyways.. This was a long rant but if anybody has some thoughts about how to convince my work to use RESTLET over others that would be great. In advance, thanks. matt ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1043393 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1045086
