One month ago today, Dave Winer described me as a patient evangelist. Some may have noticed a gap after my last web services related essay entitled Dealing with Diversity. The intent was always to follow this up with Coping with Change, but I was waiting for some clear and compelling example to emerge for the need to evolve an interface which was designed in a brittle fashion. Ultimately I even wrote an essay about the waiting process itself.
Yesterday the magic event occurred. While I knew it was only a matter of time, the actual interface that it occurred to exceeded my wildest expectations. It is one that everyone in this community can relate to. And as a bonus, the extensions do not originate from the owner.
And it gets even better. Dave's "daring and clever" use of structs points out the need more clearly that I could ever have. When "blasting a hole" for some data that one requires, one should always consider anything else that might follow. Greg Pierce nails it when he talks about the mental leaps and specialized knowledge that this proliferation of interfaces creates. Dave responds that he can't see the overhead. Touché, Dave.
So, wouldn't it be better if everybody followed a design principle of placing all non-administrivia request and response parameters into a struct? In fact, why not build this into the protocol itself, so instead of:
<member>
<name>dateCreated</name>
<value>
<dateTime.iso8601>
20020314T08:29:24
</dateTime.iso8601>
</value>
</member>
One could simply say:
<dateCreated xsi:type="xsd:dateTime">
20020314T08:29:24
</dateCreated>
Now, I am not so naïve to believe that I will convince anybody of this overnight. But I will continue to patiently make statements like this and this whenever the opportunity presents itself.
6:48:30 AM 
|
