I'm looking for a light version of REST for a Java web application I'm developing.
I've looked at RESTlet (www.restlet.org) and the REST plugin for Struts 2, but I haven't made up my mind. I'm leaning towards RESTlet, as it seems to be lighter.
Has anyone implemented a RESTful layer without any of the the frameworks or with the frameworks?
Any performance issues that you've seen because of the new web layer?
Did the introduction of REST added unmanageable or unreasonable complexity to your project? (Some complexity is understandable, but what I mean is just plain overkilling your design just to add REST)
I'm a huge fan of JAX-RS - I think they've done a great job with that specification. I use it on a number of projects and its been a joy to work with.
JAX-RS lets you create REST resources using POJOs with simple annotations dealing with the URI mappings, HTTP methods and content negotiation all integrated nicely with dependency injection. There's no complex APIs to learn; just the core REST concepts (URIs, headers/response codes and content negotiation) are required. FWIW JAX-RS is quite Rails-ish from the controller point of view
There are a number of JAX-RS implementations out there - see this thread for a discussion.
My personal recommendation is to use Jersey as its got the biggest, most active community behind it, has the best features at the time of writing (WADL support, implicit views, spring integration, nice REST client API); though if you are using JBoss/SEAM you might find RESTeasy integrates a little better.
I'm a big fan of Restlet, but I usually use it to implement apps whose primary role is to be a RESTful web service. It sounds like you're looking to add a RESTful API to an existing application. If that's the case, JAX-RS's (or Enunciate's) annotation-based approach might be a better fit for your project.
As for Restlet, I can tell you that I've been very impressed with the developers and the community; they're very active, engaged, responsive, and committed to a stable, efficient, reliable, and effective framework. My single favorite aspect of the framework is that it is a ground-up implementation of the REST paradigm; therefore there is no impedance-mismatch between a Restlet app's external API and internal implementation. I also really like how flexible it is - it can run inside a Java application container/server such as JBoss, Tomcat, Jetty, etc, or standalone, with an embedded HTTP server library.
Well, I've used Enunciate quite a bit. It uses simple annotations to provide either REST and/or SOAP endpoints.
http://enunciate.codehaus.org
Plus, Ryan Heaton has always provided top-notch support for things, too.
You know there is a new JCP API for Accessing RESTful Services, also:
JAX-RS JCP311
https://jsr311.dev.java.net/
The open source version is called Project Jersey
I am working on a REST API for gliffy.com and we ended up rolling our own. We didn't want to have to bring in Struts 2, Spring, or any other framework. I looked at RESTLet and found it incredibly confusing and over complicated.
Apache has an implementation of the JAX-RS spec, but it is not finalized and also has some oddities to it. We're tentatively planning to open source our solution, but that's not for a few months.
Rolling your own is easy, though. The Servlet Specification gives you everything you need, and you can easily connect to a database via Hibernate (see http://www.naildrivin5.com/daveblog5000/?p=39 for how to set up JPA without using EJB3).
I found restlet to be a really elegant architecture. I'm working in the .net world so it was not an option for me, but I was able to build my own framework following the same basic principles of restlet.
I have found the conversion of our WCF contract-based SOA application to REST based one has significantly simplified the application,
Related
First am not sure if this question fits here well. However couldn't think of a better place to get help. I've been tasked to list the Pros and Cons of each of these {JAX-RS, Playframework scala, MS Web Api}. I've done some research but couldn't conclude as I've not used all three to great extent. Have used playframework to create simple REST app. Have read the Web Api tutorials but have not implemented anything. Did research on JAX-RS but haven't implemented anything either. Also most of our developers are familiar with C# and introductory Java. I am more inclined towards playframework due to Scala,Akka,no server restart and scalability etc but not clear about the cons. One thing am sure is JAX-RS is standard Java EE and Web Api is standard MS stuff. Below are some of the app requirements:
Purely REST backend.
Proper authentication and authorization.
Online secure payment {Paypal etc}
Single front-end for both mobile and desktop
{angular/backbone/knockout..}
Allow users to subscribe as companies or part of companies.
Be able to connect to different databases without App restart.
Code maintenance and readability. Other members should be able to pickup without hassle.
Scalability
This is a partial answer because I worked only with playframwork 2.0 and JAX-RS.
Playframework is a MVC framework, you can use it to create some REST services but it's not focused on this kind of applications, so at least in version 2.0 it wasn't easy to add complex behavior like interceptors, etc. and you should manage authentication by yourself, I don't know if this has been improved in most recent versions of play framework.
JAX-RS is a specification to create REST services, there are several implementations like
Jersey, RESTeasy, Restlet between others. So JAX-RS implementations are built specifically to provide REST services in java. Most implementations have support to several authentications mechanism like OAuth, etc.
In my experience, JAX-RS is better to provide RESTful web services, and the code generated is in general more maintainable than the code generated in playframework, also playframework has a lot of things that maybe you don't need to use, but it will be loaded in memory when you start the server anyway. Akka it's a cool technology, but you can use it if you want it in any JAX-RS implementation.
If you want to build REST services using Scala, you could try Scalatra http://www.scalatra.org/
If you prefer java, take a look at http://dropwizard.io/, it's an embedded server that has Jersey (An implementation of JAX-RS) and a lot of cool things to provide RESTful web services, like metrics, etc, also it's easy to learn. If your team doesn't have an advanced java knowledge, this is a good option.
Playframework is great if you want an easy to learn MVC, specially for non java programmers but definitively it's not the right tool to build RESTful webservices based applications in my experience.
I don't know "anything" about WebServices in Java and eventually I need to do some REST work in Java and well I want to strart learning it this weekedn d:) So my question is do I need to first learn Java web services before I can learn REST webservices? what are the prerequisites stack of knowledge I need to learn first? and your suggested resources.
Thanks
The Java Web Services stuff only have a small relationship with REST services.
Both are "remote services" for the web, so they share the same kind of problems: object representation, security, error handling, etc.
But you don't need to learn the complexities of WS-* like service definitions (WSDL), SOAP... and a large list of stuff.
The small relationship between REST and WS in Java, comes when you want to "automatically" convert objects to XML or JSON. Because Java REST frameworks based on JAX-RS can do that by using JAXB (Java XML Bindings) an object conversion framework used also in the Java WS framework. But you don't need to use that object conversion stuff either.
Some JAX-RS compatible frameworks -like Apache CXF-, can be used also to do JAX-WS (the Java standard API for WebServices). But note that general services frameworks like CXF, have to deal with other complexities (like support for different transports) that you don't need to learn.
What you need to learn first?
Java Servlets: You don't need to be an expert on servlets, but REST services are mounted over the Java servlets infrastructure and knowledge about it will help.
Dependency injection (DI): When you start doing REST resources that access to databases or other services, you'll want to pass some collaborator objects to do that. Most of the frameworks resolves that problem by using DI. For example most of the JAX-RS frameworks can be used with Spring or Guice.
TIP: I found lots of people that uses Spring or Guice because.. tutorials shows that is the correct way to do it. But they don't know what are trying to resolve, and end with complex unmaintainable stuff. My recommendation is that before using any DI framework, first learn the concepts behind them.
(Optional) A little bit of JavaScript and AJAX. If you plan to use the REST services from a web page, is good to learn how they are going to be used.
Edited: To include a mention to Apache CXF, and use the term JAX-RS instead of Jersey that is a specific implementation.
There's a good summary of the Richardson book here: http://martinfowler.com/articles/richardsonMaturityModel.html,
I've been looking into JAX-RS lately because I really like the Java platform and a RESTful style of web development. I've read a lot about using JAX-RS for creating RESTful Web Services, but is it possible to use JAX-RS to create RESTful web sites? I guess more specifically, is it possible to use JAX-RS as a controller (to retrieve required data from the server) and then forward control to a view engine to render the appropriate HTML?
I've been googling around but haven't found any resources that show you how to do this.
Thanks for any insight/help.
I think you are having difficulty with your google searches because not many people are doing this. JAX-RS was designed for web services, so developers don't think of using it as a controller for web applications. However, there is no reason it wouldn't work.
Check out this blog post: JAX-RS as the one Java web framework to rule them all?
I think it's exactly the kind of thing you are looking for.
If you truly want to rely just only JAX-RS for your web framework, Jersey might be your best bet. Keep in mind the features you get from it are going to be bare minimum and you are obviously not going to get all the bells and whistles like what's provided by JSF, Wicket, etc.
If you know your web application is going to rely on Spring, perhaps you should consider using Spring MVC 3.0. It provides restful web services-alike and it gives you better features so that you don't need to implement most of them yourself. Granted, Spring MVC 3.0 is not an implementation of JAX-RS and based on what the Spring developer said, it seems like they will never make Spring MVC as an implementation of JAX-RS since they are already quite a few stable implementations out there. However, the syntax is pretty similar in my opinion, or at least I was able to understand them rather quickly even though I have been using Jersey for quite awhile.
dbyrne is right that almost no one is doing this. It's more conventional to use JAX-RS to dump information to JSON or XML. Then you fancy up the web browser with an RIA framework (e.g. Ext JS), which handles manipulating the DOM and injecting data as its fetched in JSON/XML form. This approach is powerful. You can write multiple, possibly non-browser clients for the service, all parsing the same JSON/XML. You can write "one-page" webapps, where all information exchange happens through AJAX after the initial pageload. I urge you to investigate and consider its strengths and weaknesses in the context of your particular problem.
Returning to your question: the answer is "sort of". This functionality is not directly provided by the JAX-RS spec (as of 1.1). However, it is in the JAX-RS reference implementation, Jersey, through the Viewable response object. See this blog post if you want to investigate further: http://blogs.oracle.com/sandoz/entry/mvcj. I want to point out that I have no experience with this side of Jersey. It has been pleasant to write XML/JSON-returning web services with Jersey, but I can't speak to this server-side HTML templating business.
Edit: dbyrne's edited his answer to include a blog post which points to the one mentioned above. I think we've both converged on approximately the same answer.
Currently I am evaluating number of web service frameworks in Java. I need web service framework that will help me to expose some functionality of existent application running on JBoss, The application is mostly developed using Spring and POJOs (no EJBs).
What I need is a framework having following properties:
It should provide tools for automatic generation of boilerplate code and save time by eliminating repetitive tasks, for example tools generating WSDL from Java (java2wsdl), tools generating endpoints etc.
Applications should be easily deployed on existent J2EE platform (JBoss), this means that it should contain as less as possible configuration files (like axis2.xml in axis2 framework).
Also it is preferred to be able to deploy web service within .war archive of existent application. (it seems that Axis2 need a separate archive for web service app.)
It will be very cool to use a combination of POJOs and Spring.
Generally, the framework should have clean structure and design (for example Spring-WS lacks it), good documentation and whatever else characterizes a good piece of software.
It is preferred that framework incorporates some standard features like JAX-WS etc. instead of vendor specific methods.
I have briefly examined
Axis2
Apache CXF
and Sun's Metro
Spring WS
But still it is difficult to decide what to use in my case:
Axis2 seems to be so low level, it requires separate application archive and lots of configurations
Spring WS seems to be too opaque and "sophisticated for impression purposes (?)"
Apache CXF and Metro probably are two frameworks that I prefer to chose from but still
I need your opinion and experience about usage of some of them in a real-world applications.
I've used CXF's forerunner, XFire, for a while now and it's not been too bad. At the time, we migrated from Axis for two major reasons: performance and ease of development. At the time (don't know if this is true now), the performance of XFire was much better than anything out there, and with annotation-driven development, instead of having to run stub generation, it was really really easy to add new web services.
CXF seems to be more of the same but better - we haven't migrated yet due to constraints on development time as well as not having a pressing reason to do so (plus the relative lack of documentation 6-12 months ago wasn't too encouraging). Additionally I haven't really evaluated the market of late, so I can't tell you how CXF stands up to its contemporary competitors.
Regarding your points:
There is no boilerplate code to be generated, the WSDL is automatically created from the service class' annotations and published by the server.
Deployment in Tomcat was relatively simple. Just define another servlet in web.xml and map a URL pattern to this servlet.
Our web services were deployed in WAR files, I'm not sure what the alternatives are in fact but this seemed to be the default and obvious way to do it.
POJOs work fine initially; we've now moved most of the web service object creation to Spring in order to wire more complex conditional dependencies in and have had no problems with this.
Documentation was a weak point with CXF originally, though having just had a look it seems to be better now. The general design and architecture seems relatively sane; slotting in one's own filters to modify the transmission details was not very painful, and extending existing classes has generally been considered (so sensible methods are marked protected instead of private, for example).
JAX-WS is full supported in CXF.
So I'm probably a little impartial as I haven't tried the other ones, but I'll give a thumbs up to having a look at CXF. It's pretty fast, relatively simple to get going with and fairly powerful if you need to tweak it.
We have tried Metro and CXF and kept CXF because Metro includes too many dependencies like Sun's APIs in its jar files which makes it difficult to integrate in another application server than Glassfish. CXF has a cleaner packaging with explicit external dependencies.
We also failed to enable Gzip compression with Metro while it worked like a charm with CXF.
I'd go with Spring WS first and XFire second. I'm a Spring user, so I'm used to the opacity.
XFire now Apache CXF was far away easier to use than Axis. I had something done very quickly using it where Axis seemed overly complicated. I didn't look at Spring WS.
I will use CXF. It is easy to use than Axis2
I have only used the Spring WS because that is what I was told to use, but it was a pretty easy use framework. If you have to go with soemthing else I would go with XFire due to the JAX-WS support.
I am embarking on a new RIA project with Java on the backend. I'm the only developer, and the app is a line-of-business application. My current stack looks like this:
MySQL || Spring(JdbcTemplate for data access) || BlazeDS (remoting) || Flex(Cairngorm)
My question is: what changes can I make to improve productivity? Manually coding SQL, server-side entity objects, client-side value objects and all the Cairngorm stuff is obviously a drag, but I'm not sure what higher-level frameworks to introduce.
What Flex/Java stack has served you well?
Manually coding SQL
Hibernate is an option to cut this out.
One thing that may be of interest is Grails with the available Flex Plugin. It's built on Spring, Hibernate and BlazeDS, so it's all there for you. It was unbelieveably easy to get it remoting stored objects and responding to AMF calls. I was using this and then moved over to a RESTful E4X implementation as I found it a lot easier to debug and tweak as I could inspect the server output in a browser and have tighter control over exactly what I returned to my Flex app (lazy loading problems in collections using BlazeDS were a headache at times).
Here is a quick tutorial showing how easy the whole Grails + Flex Plugin stack is: BlazeDS in Grails
I would seriously reconsider using Cairngorm. In my opinion it's a pretty bloated framework that introduces a lot of abstraction you'll never use. Check out:
http://code.google.com/p/swizframework
http://www.spicefactory.org
Both introduce the concept of dependency-injection into your Flex app.
Also +1 for Hibernate. I would use the standard JPA annotations on a Java class and extend that with Hibernate Annotations as you find you need additional functionality.
Check out springsource.org's new Spring BlazeDS Integration Project
Spring BlazeDS Integration is a new
addition to the Spring portfolio, and
a component of the complete Spring Web
stack. This project's purpose is to
make it easier to build Spring-powered
Rich Internet Applications using Adobe
Flex as the front-end client. It aims
to achieve this purpose by providing
first-class support for using the open
source Adobe BlazeDS project and its
powerful remoting and messaging
facilities in combination with the
familiar Spring programming model.
As alternative to hand-coding sql, aside from hibernate, you might wanna consider JPA/Toplink. And since you are already from a Spring camp, check out Spring ActionScript (formerly known as Prana), it's an IOC framework for Flex. It solves many inherent problems in Cairngorm. Also a good IDE that supports Flex/Actionscript like IntelliJ IDEA 8.
Whats missing between Flex and BlazeDS is, it doesnt have any sort of landing page where you have a listing of all the available services by just typing a url on the browser (similar to webservice endpoint).
You can try GraniteDS. It's an alternative to BlazeDS, with an actionScript generator, Spring integration (an Spring security), and if you use an JPA implementation, help you with the Lazy Initialization (in a transparent way).