Much recent discussion about the REST architecture style notwithstanding, developers often have a difficult time grasping how REST would apply to a problem domain or application they're working on. Bill Burke, JBoss' CTO, writes in a recent blog post, RESTless, RESTFul, or RESTlike? that, just as with AOP, developers need to actually implement something RESTful before they can fully understand whether REST is an effective solution to their problems.

In his quest for RESTful understanding, Burke visits several issues in Java EE, and suggests how a RESTful approach may, or may not, lead to a cleaner implementation.

The first issue he discusses is the notion of exposing Java EE resources via uniform URL addressing:

One of the cornerstones of REST is to have resource location modeled as a URI. This seems like a no brainer. When we modeled our EJB 3.0 container on top of JBoss Remoting, which is URL based, our design became much simpler and things like request failover were much easier to write... Moving to URI based endpoints made implementation easier... How many times do we run into issues in Java EE land because it does not define unified addressing of its services? Its been a big roadblock in writing portable frameworks. WS-* has to have a whole spec on the subject, funny eh?

Another issue Burke writes about is the complexity cost of interoperability:

How many of us had interoperability problems between different vendors or even different versions? Not only that, but in WS-* land most of the time you need to generate and compile stubs so that you can actually invoke on a web service. With REST, all you need is a HTTP client library. With WS-* you need the HTTP client library plus all the other junk. While HTTP is a mature, well-known, agreed-upon protocol, WS-* is such a moving target...

The question is, with the uniform interface of GET, PUT, POST, and DELETE, aren’t we just pushing the complexity to the content type? To the data that is being transferred and received? ... After thinking about it for awhile, i’ll say, that SOAP has the exact same problem. With SOAP, you still have to define and agree upon the API. The REST approach seems simpler because the protocol is set and simple, it doesn’t have the baggage of SOAP which is a protocol tunneled over another protocol (HTTP).

Burke also discusses the implications of a RESTful approach to security:

With the uniform interface approach, it does seem like it would be a lot easier to model security roles. It would just be assigning CRUD permissions really instead of assigning individual permissions to each method like you do in Java EE land. Caching is obvious because GET should mean the operation is idempotent.

Finally, Burke highlights the potential benefits of clients driving the state transitions in complex enterprise workflows:

This idea of the client maintaining conversational state and passing it to the server is compelling, at least in theory. My last blog I talked the JBoss Business Activity service. What if the client was the coordinator for business activities and managed all compensations?

Where do you think a RESTful approach would bring the biggest benefits to a Java EE application?