Just stumbled about an entry in the Groovy mailing list

def input = '''<tag id="12" />'''
def tag = new XmlParser().parseText(input)
tag.attribute("id").value = "ABCD"
println tag.attribute("id")
==>
AB

Oops. The object returned by tag.attribute(”id”) is of type String (i.e. java.lang.String) and not of some type XmlAttribute. And the ‘value’ is the private final (sic!) variable containing the String’s content (a char array). And Groovy allows us to change that value … making String mutable.

Even funnier:

...
println tag.attribute("id").value
==>
[A, B, C, D]

I always had the feeling, that Groovy was programmed first and then designed afterwards. In the last years they progressed nicely, but this makes me doubt again. This issue has been known since May 2007. But I think they just realized what it means: “Yikes! String is mutable!“

Update (April, 24th): Created a new issue, because the existing issue is only concerned with violating the “private” contract and not with violating the “final” contract.

Please vote for the issue to be fixed.

The discussion about REST vs. SOAP seems to be endless, so — why bother?

Because there seems to be a thorough misunderstanding between the two camps that needs to be resolved. A misunderstanding that pertains to different values hold by each camp. Perhaps “values” is to big a word and viewpoint might be enough, but the discussion evokes so many emotions so much “you just don’t get it” so much ferociousness, “values” seems to be the right notion. (This is my second try to put these thoughts into the right words (I even created my own blog for this), you might want to read that discussion first.)

There are two central issues at play:

1. “The Web” as an entity that can be abused
2. API design

I think the latter is more important and more fundamental, but let me try to get the first out of the way.

The “abused” Web

… or better: the abused HTTP protocol.

Proponents of the REST approach consider using HTTP as a mere transport as abusive (e.g. Tilkov, Vinovsky). For me, using a word like “abuse” sounds like putting HTTP on a throne. You have to worship it. Using it for another purpose as was intended is against the … what? As far as I remember, SMS were initially not intended for use by mere mortals, so sending a message via SMS is an abuse? James Snell puts it right:

“there will always be multiple technologies. We use the technologies that best suit the problem we’re trying to solve. It just so happens that HTTP is well suited to address a hell of a lot of problems.”

If a tool helps me to achieve a goal, I will use it. Perhaps there are better tools or more efficient ways to do things. We can talk about that, but “abuse”?. Do I abuse a hammer when I use its handle to get something out from under the bed?

I hope you can agree with me, but Stefan Tilkov throws in the following analogy:

“would you consider using a RDBMS and then defining a single table only, with two columns, ‘id’ and ‘content’ (the latter a BLOB) an abuse of the RDB”

Yes, it sounds like using a RDB in the wrong way, but if I happen to have a RDB at hand, and the data is unstructured, or simply easier store as a BLOB, so why not? Does it help me to achieve my goal? Sorry, I do not “believe” in “the Web”, the “HTTP protocol” as entities that should be worshiped and defended against the unbelievers.

So if you think that WS-* is an abuse, please let us simply state that we disagree on this point and move on. Can we?

API design

WS is centered around verbs (what you can do with things) and REST is centered around resources (the things itselves). I could stop here, because I think, that’s all there is. But then why is the debate still going on and on and on? Because this is a cultural issue. And as long as you are part of one culture it is very difficult to see value in another culture. Let me try to explain that.

When you have to integrate a bunch of legacy systems that all have some kind of (R)PC-API, it just feels natural to wrap them into WebServices. You do not have to translate all the existing verbs into their RESTful equivalent. In my comment to Stefan, I offered the following existing API as an example:

 (d) scoreCustomerMortgageRisk(customerId)
     // i.e. the customer has send in a mortgage application,
     // that should now be “scored” to decide if we can offer
     // him a credit contract

 (e) promoteToCustomer(personId)
     // a person that is in our system, will now become a
     // customer (an account will be opend, etc.)

 (f) calculateNetInterestRate(credit)

and Daniel Yokomizo translated them into one possible RESTful API:

 (d) PUT /mortage-application/{id}/score

 (e) POST /people/{id}/promotions
     =returning> 303 /customer/{id}

and with (f) he cannot see the “resource”, perhaps because there was no explanation in my comment, but he correctly assumes that this really is nothing but a calculation and he even thinks that RPC might be the right thing (so, not everyone is a zealot in the REST camp).

I think this is the best, most concrete illustration of the different mind sets. For me this looks artificial. Is “mortgage-application” a resource? Is “score” a verb or a resource? I have to translate something that looks natural to me into something unusual. If I had to document the REST services, I still would describe (e) as “Promote to Customer”, because this is the culture I grew up with. But if I had to design an API for resources that are accessible via the Web from scratch, I might try REST, especially if I have (more) people in my team that are experienced in a RESTful style. It still all comes down to my central mantra “Does it help me to achieve my goal?”

Some final remarks and disclaimers

I think XML Schema is a mess and WSDL even more so, but I would like to have a rather formal description of the XML messages I have to send and can receive. Not to generate code, but to improve my code as a consumer of a RESTful web service.

There is a difference, whether you are creating an API that is really used between two parties over the Internet, or if you are (just) connecting systems inside your company using a “platform independent” mechanism. In the latter case I would mostly prefer an RPC style in the previous case I would very thoroughly think about my prospective users (if I want as many users of my services as soon as possible, REST is much simpler to use than WS-*).

I do not question that I can translate each and every verb of my RPC-style API into the four HTTP verbs and some deliberate URL. I know about Turing machines, but I think we all are happy that we do not have to program Turing machines directly. Restricting myself to a set of very strongly defined verbs, might even help, but I fear that eventually the URIs will be very arbitrary. If that is true, nothing will be gained.