So if you're writing (or generating) contract/interface-level code which can't late-bind to all resources, everywhere, you're not doing REST ...
Is this "We don't need no stinkin contracts!" meme a reaction to the non-web-friendlyWS-* world, what with it's overly complex and verbose schemas? Because I think there'splenty of room for some people to apply contracts to parts of the web. I certainlydon't believe the entire web can be fully described using some all-encompassing schema language; but smallpieces? Sure.
I guess what I don't understand, is how you are supposed to describe your servicesto someone without some kind of meta-data describing the service. Every 'web api'I've ever seen has human readable text describingthe URIs, the data expected as input, and the data expected as output. (Admittedly, most of these 'web api's violate best practice HTTP principles somehow, but I think that's notan issue here; they could all be refactored to be be better HTTP citizens.) That human readable text is a contract; an interface. In English. Which is terrible. I'd rather have a machine readbleversion of that contract, so I can generate something human readable from it.And perhaps a validator. And some client stubs. Maybe some some test cases.Diagnostic tools. Etc.
What is the the alternative to describing your services?How is anyone going to write code to use these services, if they don't know whereto send requests, what verbs to use, what data to send, and what kind of data to expect?Instead of Flickr producing a description of their web services like this, they're simply supposedto say "Flickr is now fully REST-enabled. Start here, and have fun!" ??
As with data modelling,I don't feel like there is a single answer to what schema or contract languagebe used. I'm not initially sold on WADL (seems too verbose), and certainly wouldn't use it if therewas something else, better, for whatever project I was working on. The shape ofthe schema language isn't important, as long as it works for you.
So I guess contract-driven HTTP interfaces aren't REST. But this is an areaI'm interested in; what name should I use, so I can avoid be labelled as "not doing REST" while I'm optimizing my use of the web by being a goodHTTP citizen?