Aristotle Pagaltzis asks, “Does REST need a service description language?”
I’m convinced the answer is yes, or at least I’m seeing enough case where having a description language would change REST from “nice idea” to “let’s do that!”.
There’s WSDL 2.0. It’s static-typed, early binding description language that assumes whatever you’re describing is a SOAP service. You can hide the SOAP envelope, trick it to use query parameters, but fundamentally it’s still SOAP. A REST description language would be dynamically typed, and favor late binding. And it will support all the protocols you need it to support, namely HTTP, going for simplicity over premature abstraction.
But there’s some other fundamental difference that’s bugging me. The WSDL/SOAP world assumes all services are pre-existing objects, you just need to know where they are and which methods they support. The REST world is functional style, every resource is a function, and you can pass data and functions around. Think Java vs Lisp and the differences become obvious.
And it’s bugging me, because I’m asking myself, can we take that distinction one step further? At the heart of WSDL (and also WADL), is the idea that services require meta-data, and meta-data is just another form of data. Some static bits and bytes, that so happen to take the form of XML.
What if the service description itself was, like the service it attempts to describe, functional in nature?
For example:
orders() {
get "orders"
}
order_for(orders, customer) {
get orders().select("order[customer={customer}]/href")
}
orders_on(orders, date) {
get orders().select("order[created={date}]/href")
}
After all, we’re dealing with behaviors here. What if, instead of trying to map all the behaviors into static constructs that can be hammered by XML, we try something new. We describe how to drive that behavior to get the results you want.
Of course, that might end up not working as well as static description for dynamic services, or work very well but just require a certain level of experience (*cough*lisp*cough*) that sends most developers running for the hills. But still, what do you all think? Is anyone working on something like that?