REST is pro-contract

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!

8 thoughts on “REST is pro-contract

  1. Steve Jones

    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 :)

  2. Mark Baker

    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?

  3. Steve Jones

    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.

  4. Mark Baker

    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.

  5. Mark Baker

    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.

  6. Steve Jones

    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.

  7. Mark Baker

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *