That’s a good first step - agreement on “not required” - I have arguments with people all the time who claim that meta-data is bad - inherently bad - and their rationale, oddly enough: “because that’s WS-* all over again”. Putting me in an odd position of having to say something positive about WS-* :-)

I also agree there are some bad, bad things that can happen with reverse engineering the meta-data from an implementation, generating magical wrappers, etc. That’s actually a shame, because, if you know what you’re doing, it’s obviously quite possible to infer metadata from an implementation (that you’ve written), and generate useful wrappers (for you to use). The problem is you have to know what you’re doing, and most people don’t.

I also agree with your fear of code generation, magical annotations that distribute systems, and ignoring lessons already learned.

Part of what I think is the problem: the very name “interface definition”. RESTful systems only have one interface, so entertaining creating new ones is at the least confusing.

Also, the most interesting and intricate parts are left out of most IDLs (CORBA, WSDL, Java/C# interfaces, …): states, transitions, pre/post conditions, and everything else that is maybe described in a blurb of text.

My suggestion for what we should be talking about is a “state definition” language. REST is “State Transfer” with a uniform interface. Providing an extensible, composable, shared semantic between providers and consumers to document high level states and resources makes sense to me.

The tooling support that an “SDL” could provide is to abstract away some of the mechanics of HTTP interactions, but not the human coded logic. For example: a shopping agent needs some specific logic to decide when to “checkout” and buy things. That is the stuff developers need to think about and write. Once that decision is made finding the right URI, verb, and content can be assisted by an engine looking for meta-data corresponding to that shared SDL.

But the fact remains that there’s no need for an IDL-like language for REST, as the REST interface is uniform and is already fully defined. If you were going to create an analogous language for REST, then as John explains above, you’d want the language to help define interaction details based firmly on RESTful foundations, rather than focusing on object interfaces, operations, parameters, and inheritance relationships as OMG IDL does.