No one can deny the positive impact Java has had on the software development landscape over the years or that it and the JVM remain the dominant general solution for many developers and applications. Whether it's been CORBA, Java EE, SOA, REST or Web Services, Java has been able to support them all. Given the ubiquity of Java and REST, it was only a matter of time before a standards based approach to merging the two would appear and that was JAX-RS, which was introduced in EE6. There are many JAX-RS implementations, including Jersey (the reference implementation) and RESTeasy, which are used widely.
Over the years there has been criticism about JAX-RS though, particularly around whether or not it encourages RESTful design. Some of these issues were taken up by the JAX-RS 2.0 technical committee, but as recently as JavaOne 2012 there were still questions around the standard. Earlier this month, Zapthink entered the discussion with an article that once again questions whether Java or even JAX-RS is appropriate for building RESTful applications.
The ongoing efforts of the Java Community Process (JCP) have augmented the capabilities of the Java ecosystem in order to tackle a wide range of new problems and situations. This ongoing work on Java may continue to meet your needs for years into the future. But then again, maybe not. The heavyweight model-view-controller (MVC) architecture of Java EE, or simply the object-oriented context of Java more broadly may not support alternative architectural approaches.
Of course there are thriving JVM communities that are not related to Java, such as JRuby, Clojure, Scala and JavaScript, and you don't need touch Java EE in order to utilise many of the capabilities within, such as transactions, security etc. And some of these languages have their own approaches to building RESTful services. However, Zapthink believe that Java is particularly poorly served with JAX-RS:
Unfortunately, JAX-RS is a classic example of shoehorning. It adds some RESTful capabilities to Java, but fights the RESTful architectural style every step of the way. Case in point: the Hypermedia as the Engine of Application State (HATEOAS) constraint. JAX-RS 1.1 didn’t support hypermedia at all, which essentially meant that we would have to simulate HATEOAS characteristics by utilizing core Java capabilities. To make JAX-RS fully RESTful, you would have to design applications that satisfied all of REST’s architecture constraints, compensating for those features that did not have adequate support during development. JAX-RS 1.1 provides adequate support for satisfying some REST architecture constraints, but punts on HATEOAS.
This lack of hypermedia support was something that the JAX-RS technical committee have tried to address in the latest version, but it has not gone far enough as far as the article is concerned: JAX-RS uses Java annotations heavily but there are no annotations to express hyperlinks, leading to ad hoc approaches when they should be part of the standard. According to the article, there are also other areas where even the new version of the standard fails to deliver, although it is arguable whether or not these belong within JAX-RS or in some other standard:
It’s also important to standardize custom media types whenever possible, and you must also select which standard media types and custom media types you should use. Furthermore, the Service discoverability design principle requires having hypermedia controls in place, based on the REST HATEOAS design constraint. Discoverability provides a way of making the protocol self-documenting.
Finally there is one significant constraint imposed on JAX-RS that Zapthink believes prevents it and Java from being appropriate for RESTful services. As Arun Gupta explained when discussing the early draft of JAX-RS 2.0, there are two types of links within hypermedia:
Linking resources together is one of the main RESTful principles. There are structural links that are used to avoid sending a complete representation of a resource and enable lazy loading. The clients can follow these type of links to retrieve the "pieces" they need. A transitional link is used to update the state of a resource and is typically identified by a "rel" attribute. Structural links are normally in the entity; transitional links could be in link headers or the entity.
However, despite the fact that JAX-RS 2.0 only supports transitional links, Zapthink believes neither are strictly necessary for RESTful services:
If we simply take a Java object and convert it into hypermedia, we end up with links that represent all the various method calls on the associated object instances, resulting in excessively large, complex representations. Instead, JAX-RS encourages transitional links which enable the client to drill down to the underlying aggregate data. But if we weren’t handcuffed by the Java object structure in the first place, we’d never bother with transitional and structural links. Instead, we’d design our hypermedia applications to support discoverability. In other words, a core Java pattern becomes a hypermedia antipattern.
Apart from the fact that JAX-RS 2.0 may still be deficient for building RESTful services, the author's conclusion is that you need to remember that REST is not an implementation but an architectural approach:
People are often confused while developing with JAX-RS and thinking REST. JAX-RS is not REST design; rather, JAX-RS should support good RESTful design. Furthermore, the use of JAX-RS API does not lead to the creation of fully RESTful Services unless you have completed proper RESTful design beforehand. The design has to ensure that you have satisfied all RESTful architecture constraints.
Of course this is something that others have said before in relation to REST or SOA. But are there some fundamental problems with JAX-RS or Java for building RESTful services as the Zapthink article describes? One of the commenters on the article asks:
In all seriousness, what language would you suggest as a replacement for Java when building systems with a RESTful approach? I understand that Java is getting “long in the tooth,” but I firmly believe in the benefits of strong typing and other programming practices that Java embodies. Would you consider Scala (the next logical evolution of Java) more suitable? If not Scala either, then what would you suggest?
And the author responds:
I don’t favor any one language over another here simply because I firmly believe that any programming language can be advantageous as long as it provides adequate support for implementing REST compliant architecture. Of course, architecture will have certain influence of the language of choice. But more important here is focusing on designing application to conform to REST design constraints.
Which still leaves the question: is Java being shoehorned in to RESTful design, and particularly any more than other languages?
