> Jonathan, can you elaborate? Why do you think jersey is > better? Have you any experience of integrating it with wicket?
We use Jersey for REST here, mostly because it is Sun's reference implementation of JAX-RS (and thus will most likely be updated fastest). As for the options: * Restlet: Implemented the REST ideas in a custom way before JAX-RS was specced, spec support seems "crowbared in" * RestEasy: Is a JBoss project, and there is as always a certain danger of the "fish hook" that leads you into the rest of the JBoss stack. Now, we are probably going to use JBoss ESB for some service orchestration, but their ESB will not support REST-based services (I think only Mule and ServiceMix do at the moment) until the 5.0 release which is a way off. * CXF: Axis and Xfire had a child, but it might be that it ends up as a bloated mess since they are trying to implement all sorts of services in one library. We do use it for SOAP services though. What you need to be aware of is that the JAX-RS spec is purely server oriented, and each implementation adds its own extension (like client libraries and proxying, content type support, JAXB/JSON magic etc.) so you do run the risk of "vendor lock-in" whichever you pick. But can you really have vendor lock-in over free stuff? :) Wicket could conceivably be morphed into a top layer to REST services (human-oriented interaction using forms and resource links), but to work "seamlessly" you probably end up with some very hairy URL coding strategies, resource models etc. that could make "wicket-rest" break Wicket for ordinary MVC purposes if running in the same webapp... --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
