2007/05/10
So that whole “contract thang” has popped up again in the echo chamber. I’m going to pick on Steve Jones a little (more 8-), specifically something he says in his latest piece;
Where I do disagree though is whether this is a good or a bad thing to have these camps. Now I’m clearly biased as I’m on the contract side […]
Hold it! Let’s make sure we’re having the right conversation here. It’s not “pro contract” vs. “anti contract”, it’s simply “many contracts” vs “one contract”.
Resume!
Hopefully. I’m including the exchanged information as a part of this formal contract, i.e. the XML docs should be validated, maybe even using Schematron and the like on initial reception of the documents. If you are happy with that as well then it definately is all peaches and cream :)
Hey Mark, just saw Phil Windley’s post (http://www.windley.com/archives/2007/05/marc_hadley_on_wadl_a_restful_api_description_language.shtml) about Mark Hadley’s presentation on WADL. What are your thoughts on it?
Sure, validation can be done if the recipient wants, but it shouldn’t be required. In other words it’s an implementation detail, and so not something I’d consider part of the contract. Still peaches?
Its a bit cruel to do validation that you aren’t telling your consumers about, so its fine not to trust the buggers but I do think its a good idea to publish the standards to which you will hold them to account.
Todd – I’m not a big fan of WADL. As I say in this post, REST is about using a single contract for all services, and you really only need a description language to describe *differences* between contracts.
All WADL really achieves (in the common way I’ve seen it used) is to more tightly couple client and server since the client assumes things specific to that service.
Steve – I agree. But I think any reasonable data standard will be extensible so that it’s immaterial to the sender whether you validate or not.
Not sure on it being immaterial, if you validate it says “I will kick you out if you don’t obey this specification” if you don’t it says “lob any old crap down and we will see what I can handle”. Now you could argue that the later is more flexible but (IMO) it does require you to assume a level of intelligence at the other end that can’t be guaranteed.
I think it’s more the former, but where the specification has to be extensible such that v12 documents can be reasonably understood by v1 software, primarily by using a so-called (and poorly so) “must ignore” rule on extensions.