jamesladdcode.com

I was reading a post on the blog by Simon Harris about a suggested RESTful way of requesting information in ranges, and I wondered why we don’t use the OPTIONS keyword more, since we appear to be right at home with GET, PUT, POST and DELETE?

There is no standard for REST that I am aware of and maybe this is the reason and maybe we need someone to champion a draft or suggested ’standard’ for using REST and REST-enabling web sites.

I’d like to propose that sites use OPTIONS to enable a method of discovering what resources a site exposes. For example, an OPTIONS request to www.acme.co may respond with an XML representation like this (this is rough but I’m sure you can follow it):

<resources>

<services>

    <service name="consulting" uri="/consulting"/>

    <service name="support" uri="/support"/>

</services>

<products>

   <product name="acme torch"  uri="/product/torch"/>

   <product name="acme battery" uri="/product/battery"/>

</products>

<gateways>

    <gateway name="shopping cart" uri="/cart"/>

</gateways>

</resources>

From this the whole offering of the site is discoverable in a reasonably uniform way. Further OPTIONS request would make possible finer inquiry into the supported options and functionality.

This approach would keep the HEADers free to do what they do in regards the client to server conversation and the supported representations of resources.

If we all took this approach then clients could become smarter and provide more automated and regular features on top of the human readable site. Imagine asking your browser to find the cheapest iPod and it going through your bookmarks or google search results and interrogating each site for the best price, heck, it could even make the purchase too.

Want to work more on this, then drop me a line.

I’m very pleased to see that Robert C. Martin has another book coming out really soon. Clean Code: A Handbook of Agile Software Craftsmanship.

You can see the table of contents over at the ObjectMentor blog here.

It will be nice to get all these topics covered in one book.

Last night the Melbourne Patterns Group was canceled but ThoughtWorks invited the few who turned up to participate in their internal study group.

They posted a couple of topics on the board and people signed up for the ones they would most like to discuss, and Qi4j was one of the topics.

What is Qi4j ? From the web site:

The short answer is that Qi4j is a framework for domain centric application development, including evolved concepts from AOP, DI and DDD.

Qi4j is an implementation of Composite Oriented Programming, using the standard Java 5 platform, without the use of any pre-processors or new language elements. Everything you know from Java 5 still applies and you can leverage both your experience and toolkits to become more productive with Composite Oriented Programming today.

Why should you care ?

Because it brings mixins to Java (in the absence of closures - soz, couldn’t resist plugging them again)

Now you can keep the behavior and state related to that behavior physically separate from other state and behavior, making your classes simpler. No more changing the state of a variable and finding something else no longer works. Ok, this can still happen but you get my drift.

In practical use you can keep the behavior and state related to persistence separate from the rest of the domain state and behavior. So now you will know that the Id field is related to Hibernate persistence and not some domain specific Id, and you also have the persistence methods like save and find separate. Similarly you could keep validation behavior and state separate from other logic and state.

The benefit is not just this separation and support for the composite pattern, but a great mechanism for ensuring behavior is implemented only once, yet available to anyone who needs it mixed into their class. Less code hopefully means simpler and easier to understand code and less bugs.

If you get a chance, then check it out.