Why is such prescription attractive and interesting? Because API restricts the client to talk the same language of the server. But once you have an useful service written in a programming language say, Java, it is natural to have clients who wants to use the service but does not speak Java. REST (Representational State Transfer) prescribes that the client and server communicates purely via exchange of resource, not by client invoking server API method and receiving return values as a result .
The other important thing REST prescribes is that the server be stateless between a client's successive requests.
Such simple but powerful principles of REST had been a guiding force to architect the modern world wide web -- with excellent scaling characteristics even at a virtually unbounded scale.
On the opposite end of the stateless spectrum lies the principle of JEE Application Servers -- where the server maintains state of everything and there exists one (or multiple) API for everything. Such server-centric, stateful, API-oriented principles of JEE led to several roadblocks. The poor judgment or design choices -- in technology as well as in real life -- often leads to undesirable complexity. JEE became so fraught with mind-numbing complexity that one entire JavaOne conference was devoted to restore simplicity(or sanity) to the platform that aspired to be the transaction platform for the web (and ended up defining multiple definition for Transaction -- begin, commit, rollback -- in multiple packages). Also from rendering static Java Server Pages to making EJB 1.0 remote stubs to make a network trip to read a persistent property to mega-megabyte HTTP sessions -- in many ways server-centric, API-bound JEE principles had not proven as effective as URI-based, stateless server principles of REST.
I found REST principles concise and elegant. I also find Java Persistence API (JPA) providers have done a great job in standardizing and rationalizing the classic object-relational impedance mismatch. JPA is often misconstrued as a mere replacement of JDBC -- but it is much more than JDBC and even more than Object-Relational Mapping (ORM). JPA is be a robust way to view and update relational data as an object graph. Also core JPA notions such as detached transaction or customizable closure or persistent identity are seemed to neatly aligned with REST principles. Based on the perceived synergy of these two prominent styles -- I decided to experiment on unifying URI-based REST and JPA and called in JEST.
The unification was simple and concise. The unification was manifested as a standard HTTP servlet called JESTServlet. The servlet is generic. You can take any existing any JPA persistence unit and JESTServlet will let you browse your data/domain model as object graph, or query with JPQL query from any web browser. You do not need to add any annotation, browser plug-in -- nothing. JEST is completely meta-data driven. All you need to do is to deploy JESTServlet in the same deployment unit of your existing application.
- I have started to describe JEST at OpenJPA site.
- Also I had an interactive and productive a presentation on JEST at LA JUG
- Another presentation is coming up at SFO JUG