REST API for Java – But Will It Be Simple Enough to Actually Be RESTful?

Following Cote’s links, I found that there is a JSR proposed for a RESTful Web Services API. It would be ludicrous for this JSR to not be voted in, so let’s assume it will go forward and become a massively committee-driven document someday, perhaps even accompanied by a reference implementation. The burning question on my mind is: will it actually be simple enough to use?

Hopefully, the JCP learned it’s lesson from the community fallout on WS-* Java APIs. And hopefully it has learned from the RoR community that developer productivity rather than infinite pluggability is actually a key requirement. Think Spring and DI, not commercial black box components and SPIs.

So let’s see if they can actually pull off an API that lacks the following:

  • Factory classes for roundabout instantiation
  • Manager classes for implementation abstraction
  • Engine classes for what should be behind the scenes servicing
  • Interface/Implementation pairing ad nauseum (I’m so done with the Bridge pattern)
  • Pluggable runtime providers – how about just provide a good one OOTB and be done with it?

Can they possibly do it without the same old, tired patterns?

Technorati tags: , , , , , , ,


9 Responses to “REST API for Java – But Will It Be Simple Enough to Actually Be RESTful?”

  1. 1 Cote' 22 February 2007 at 2:57 pm

    Awesome. I like how you broke down The Usual Java/JEE Design patterns šŸ˜‰

  2. 2 James McGovern 23 February 2007 at 5:48 am

    I agree and disagree at the same time. Yes, we need fresh thinking here but likewise familiarity sometimes breeds success.

  3. 3 scott 1 March 2007 at 7:10 am

    Familiarity breeds success but is also the siren of mediocrity. I got excited when I heard about scripting on the Java platform because I pictured inlining and bootstrapping – but was disappointed to see a big family of classes like I mention in this post. I think the Java community’s best response to other lightweight development platforms is to cannabalize in the name of simplicity – and build a new context of familiarity around that.

  4. 4 JT 10 March 2007 at 10:17 am

    Hi Scott,
    I like the depth of your analysis.
    Do you see JSON and JSR-311 addressing a large percentage of the Java developers needs? What about NIO?

  5. 5 scott 27 March 2007 at 9:26 am

    Hey JT –

    I don’t know if JSON will save 311 or not, but I suppose building JSON support in will make it presentation tier friendly for web app developers. I’m more interested in the server-side – I would hope that they would build on annotations and allow for some extremely simple exporting of entities without having a lot of coagulating infrastructure classes required.

    I don’t frankly know how NIO plays into this – do you? I am not terribly familiar with NIO, but it seems lower level than the APIs they will addres with 311.


  6. 6 JT 28 April 2007 at 12:50 pm

    Pleased to hear you mention annotations. There is interesting things emerging in the W3 working groups around annotations. Between XHTML, XFORMS, Annotea and SAWSDL it seems like we are do for an Aha! moment. The question is whether or not RDF will become supported by non-Oracle RDBMS. If not, I expect the XLINK groups to reinstate and hook in via FOAF. Take care!

  7. 7 Stephan Koops 18 June 2008 at 4:14 am

    Did you take a look of the current state of JSR-311 / JAX-RS ( What do you think about it now?

  8. 8 scott 24 June 2008 at 9:30 pm

    Stephan – no, I actually haven’t taken a look at these APIs in awhile, as I have not been in need of remote messaging. How do they look to you?

  9. 9 Stephan Koops 26 June 2008 at 3:54 am

    Hi Scott,

    I think it looks good: JAX-RS uses annotations for a lot of requirements. You can see a small up-to-date example on and how to use it with the Restlet JAX-RS extension.

    And to some of your points:
    * The resource classes has no access to the runtime environment, so the developer ist not required to know or think about, how it works.
    * You could add your own providers as you need; you could also add an json provider; some runtime environments contains such a provider.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Diabetic Runner Challenge – 500

Flickr Photos

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 License.

Site Meter

RSS Latest Runs

  • An error has occurred; the feed is probably down. Try again later.

RSS Latest Routes

  • An error has occurred; the feed is probably down. Try again later.

%d bloggers like this: