RESTful daydream #4

This blog post has gone through far too many iterations, and taken far too long to write! It got much shorter in the process though.

It started with an idea I had, in an innocent sort of way. I thought if I looked at the JCR specs for a bit I might find some kind of way of building a non Java interface with them. You know, maybe there might be a nice REST architecture waiting to get out. But of course there is no such thing. It is an application definition. There are not even that many ways of implementing it, other than choosing your object persistence method to be a database, file, or something else.

The REST architecture is notionally provided by another layer, such as Apache Sling, but Sling is in no way a REST layer, it is a URL dispatcher and scripting and application layer with which some REST style applications can be developed. With that you end up with a pretty heavyweight development framework, indeed together you have much of Day’s CMS offering in effect, rather than a lightweight REST repository solution.

I had a look at CMIS again. Fielding once laid into CMIS for not being REST and you can see why, although some improvements have been made since that. Although resources are discoverable through hypertext, there is a fair amount of semantics that needs to be known to understand what a type or a checkout means, and the search queries are obviously just RPC wrappers. It is not too bad though, but unfortunately the data model does not map well onto web content management right now for obvious historical document management reasons. Fixable? I think it serves a part‎icular purpose well and should probably not be forced into anything else, as we need it to succeed in its field.

Day claims that JCR is not a Java standard in an odd way, that you can implement the API in another language. Thats a strange argument to make, especially as the types are defined as Java types, and standards without interoperability are pretty vague. Without some sort of wire format or ABI this is meaningless outside the JVM world. People are making JCR like repositories in PHP but outside any standards process, so in the end this just becomes a PHP repository project; Typo3 seems to be building another, also closely aligned to JCR.

The problem with these efforts is that it is not helping the balkanization of web CMS, which is already fragmented by language and API, which is ridiculous in an industry that is about the web. The web has an architecture (REST) and an API (HTTP). Building web content management on Java APIs or PHP APIs or .NET is a legacy way of thinking; it is acceptable for document management given its role in existing enterprise architectures, but it is not going to work if we want to get widespread acceptance in web development; in the short term it is the easy path, it is what people are used to, but a forward thinking industry needs to look at defragmenting the landscape and building future proof tools.

The odd thing is that a web content repository alone surely lends itself to a simple REST architecture. Content is after all lots of small resources with relations. Hypertext. It is pretty much in presentation a fairly dumb web application, although with a fair amount going on behind the scenes. It takes content, relates it to other content, and serves it back, with authentication and versioning. Everything else is in other system layers, transforming it and so on. Not simple, but well defined; lower level than JCR + Sling say

So we need to work on a web content repository model, as a community. Process wise, it makes sense for this to sit in an organization like AIIM, as a content management based industry body. It may well be that what ends up coming out of this is more standardized architectures and semantics and open source implementations rather than the tighter prescriptions of JCR and CMIS; I have some ideas along these lines that I need to code up. I have had some discussions and there is a degree of interest in some sort of solution; who is interested? Or is infrastructure dead, everything ust wants interfaces?

Dilbert.com

1 Trackbacks

You can leave a trackback using this URL: http://blog.technologyofcontent.com/2009/10/restful-daydream-4/trackback/

  1. [...] This post was mentioned on Twitter by Claude Vedovini, Michael Kowalski and Justin Cormack. Justin Cormack said: blog post on rest content repositories that I promised way back http://bit.ly/27RECr (@parkcoll as discussed the other week) [...]

7 Comments

  1. Justin – many thanks for this post, it is great to see such a proposal from someone else than one of my usual JCR suspects! (and I apologize if I should have added you to that list earlier ;-) I don’t know much about AIIM but if you envision coming up with “more standardized architectures and semantics and open source implementations”, which makes perfect sense, Apache seems like a good fit as well. Jackrabbit 1.6 does provide an http remoting layer, which is not complete but quite usable already. Having a standardized (as in “industry standard” at least) RESTful interface on top of JCR often comes up in discussions with Jackrabbit/Sling folks, so it might be worth discussing your ideas there.

    [1] http://dev.day.com/microsling/content/blogs/main/jrnativehttp.html

    Posted October 6, 2009 at 20:28 | Permalink
  2. One of the most critized point about the JCR is of course the “J” letter at the beginning. What would be perhaps interesting could be the extraction of the section 3 of the spec (Repository Model) and to try to transform it into a language agnostic RESTful Model. Then you would of course have to host and standardize it under anyother umbrella than the JCP. Such a JCR 3.0 revision would then only be the details of the JEE instance.

    Now which organisation could host such a generic model (OASIS; IETF;…)? Which legal issues with the current JCP process which should has some IP rights on all these resources?

    I am not part of the JCP/JSR170/283 expert group, but I am sure this topic was already discussed last year. Especially with the start and raise of CMIS. But now with the apparition of PHP “forks”, yes I agree, it would perhaps make sense to host/maintain & discuss the model outside of a pure Java/JCP lobby.

    Now all these standardization effort requires lots of time and energy. So after the JCR and CMIS who is ready to invest more money into this?

    Stephane

    Posted October 7, 2009 at 08:04 | Permalink
  3. The jackrabbit HTTP/webdav remoting layer is not a REST layer, but it would be a useful addition to the standard, and would help some people, and it would certainly allow interop testing of non Java implementations. It is not really the kind of model I had in mind though…

    In terms of who is ready to invest money, thats a good point, and one of the things I am trying to find out. It may be that the timing is not right now; there is a demand for it but not a willingness to spend the time now…

    Posted October 7, 2009 at 08:39 | Permalink
  4. Hi, interesting post. Some of my thoughts about it here [1].

    But why do you say that “jackrabbit HTTP/webdav remoting layer is not a REST layer”?

    Cheers Michael

    [1] http://dev.day.com/microsling/content/blogs/main/restfuldaydream.html

    Posted October 7, 2009 at 16:44 | Permalink
  5. Michael, thanks for your thoughts, with regard to your query, so many reasons! How could anyone think it is a REST layer? Transactions in headers! No hypertext! No discoverability! About as far from a uniform interface as anyone has ever gone!

    Posted October 7, 2009 at 23:14 | Permalink
  6. Justin, thanks for clarifying. I agree with you that the Jackrabbit http interface some design bugs in terms of being RESTful (hypertext comes to my mind as well), but they should be fixable IMO. Good that this discussion gets going. Cheers Michael

    Posted October 8, 2009 at 09:02 | Permalink
  7. ?

    I agree with your post. As JCR is just a Java repository API, I never understood how it was supposed to help interoperability, especially given the fact that most CMS are implemented in PHP.

    For interoperability, we need a protocol, not an API!

    Posted October 8, 2009 at 12:25 | Permalink

Post a Comment

Your email is never shared. Required fields are marked *

*
*