Its also interesting that you said WSDL and not SOAP as a whole… because I think the sweet spot lies in REST which properly strict APIs ala WSDL.

I’ve been writing a lot of client/server applications in the last 3 years and ofcourse I have always used RESTfull interfaces b/w the two where I had control them, but recently (about 6 months) I’ve had to deal with ASN.1, SOAP, WSDL, CORBA and finally understood what I had been looking for while doing my REST services. I had been looking for an IDL to basically automate my creation of client code. While REST servers are easy to author, there’s no easy cut dried and pasted way of creating clients that implement the server protocols.

I want to believe any decent developer will reach the same conclusions after developing a little bit too much REST clients against services. Too much typing man.. too much brain dead http calls, json.dumps(), etc

To quickly end this rant , I’ll summarize by saying… We tend to throw away the good lessons from the past for the next sparkly new invention/innovation, instead of building on them… ASN.1 was developed a while back and IDL is generally agreed to be advantageous when designing protocols/services. Thought SOAP may be generally bloated and thought REST may be lighter weight and generally easier to develop against, REST still needs something akin to WSDL… an IDL that allows RESTfull services to be easily spec’d and allow clients to automagically generate code for talking to them.

Oh… and a closer look at Thrift and Protocol Buffers also shows that this is a problem worth solving.

- Uniform interface –
If a human or a machine looks at the WSDL interface, how do they tell which methods create the resource, update or delete the resource? You would have to get everyone to use the same naming conventions in order for it to be clear without consulting external documentation, which a machine can’t do and won’t easily be able to understand. With REST it’s very clear what standard HTTP methods you can use in the most common CRUD operations.

- Hyperlinks in resources –
A well-designed REST API uses hyperlinks in the resources, so you know what else you can do with the resource. This is the HATEOAS feature and is the most often looked aspect of REST. It allows a machine to discover what states are possible for a resource and what are the related resources. That feature built on the uniform interface, in my opinion, actually makes it easier for a machine to determine what it can do when
in encounters a completely new web service. And with the support of AtomPub
some of these states are more explicit for a machine to understand. With WSDL it’s easier for the machine to parse, but a human user still has to map those operations to their actual meanings before anything useful can be done.

- Known side-effects –
The caller clearly knows side-effects and which calls are idempotent. Whether a SOAP method call is going to have side-effects is not known. With REST it’s known implicitly by the HTTP method being used by the caller. WSDL does not encode what web methods have side effects.

- Standard error codes
With REST you have a standard set of HTTP error codes. Sure you have the SOAP fault, but my understanding is the interpretation of that fault is mostly application dependent. There is no standard way of encoding specific failures related to the operation that a machine can understand. On the other hand, with REST combined with known side-effects, a caller can make a more well-informed choice about the repercussions of re-trying a REST call.

Its also interesting that you said WSDL and not SOAP as a whole… because I think the sweet spot lies in REST which properly strict APIs ala WSDL.

I’ve been writing a lot of client/server applications in the last 3 years and ofcourse I have always used RESTfull interfaces b/w the two where I had control them, but recently (about 6 months) I’ve had to deal with ASN.1, SOAP, WSDL, CORBA and finally understood what I had been looking for while doing my REST services. I had been looking for an IDL to basically automate my creation of client code. While REST servers are easy to author, there’s no easy cut dried and pasted way of creating clients that implement the server protocols.

I want to believe any decent developer will reach the same conclusions after developing a little bit too much REST clients against services. Too much typing man.. too much brain dead http calls, json.dumps(), etc

To quickly end this rant , I’ll summarize by saying… We tend to throw away the good lessons from the past for the next sparkly new invention/innovation, instead of building on them… ASN.1 was developed a while back and IDL is generally agreed to be advantageous when designing protocols/services. Thought SOAP may be generally bloated and thought REST may be lighter weight and generally easier to develop against, REST still needs something akin to WSDL… an IDL that allows RESTfull services to be easily spec’d and allow clients to automagically generate code for talking to them.

Oh… and a closer look at Thrift and Protocol Buffers also shows that this is a problem worth solving.