Pete Lacey is a well-known critic of the SOAP/WSDL-based approach to Web services, and a fierce advocate of the REST style. (See our previous coverage of his "S stands for Simple" post and an email interview InfoQ did back then.) In this interview, recorded at QCon San Francisco, Pete Lacey talks to Stefan Tilkov about the reasons for his disillusionment with SOAP in the light of his personal involvement with it for a long time:
Watch the full interview (32 minutes).
When I was working for Systinet I was a true believer but then, as many people have gone through this experience, the more you try to use it the more time you spend bashing your head against the wall, especially in those early days where interoperability was incredibly difficult, and then you dive deep into the XML schemas and specifications, and you looked really closer to the WSDL specification, and find that there is a lot of cockroaches in the corner.He describes the ideas behind REST and addresses some of its perceived shortcomings:
I mean from transactions for instance I don't think that transactions are missing. I actually have a feeling, I could be wrong, I don't think I am, but I think that nobody is actually going to use distributed WS-* transactions simply because that's never going to scale in any meaningful way, horizontally or vertically. So that's a case of you aren't going to need it I think. But if it turns out that you do need it, we actually have some nice patterns for you, and if you don't want to use the RESTful patterns for transactions, nobody is going to come and arrest you for cheating and inventing your own kind of transaction processing on the fly if you care to.Finally, he discusses cases where SOAP/WS-* or RESTful HTTP might be more appropriate.
But you also said security and I would say there is kind of a big gaping hole as regards security, in a sense. The security picture of REST, REST doesn't talk about security really. We talk about security for HTTP and that amounts to SSL, HTTP Basic Authentication and HTTP Digest really it's about it. Now the good thing is that SSL just rocks my world. It's proven, it's been beaten to death for over ten years, trillions of dollars for business are conducted over SSL, it does its job. In fact there is a very strong argument that says you don't have security unless you have SSL. You combine SSL with HTTP Basic and you have a lot of what you need. You can meet more that ninety percent of all your security needs.
Watch the full interview (32 minutes).
Community comments
Loose Coupling
by Jean-Jacques Dubray,
Interview Link is not working
by Prajwal Tuladhar,
Re: Interview Link is not working
by Ryan Slobojan,
@Jean
by hernan garcia,
Re: @Jean
by Jean-Jacques Dubray,
Loose Coupling
by Jean-Jacques Dubray,
Your message is awaiting moderation. Thank you for participating in the discussion.
Pete:
I really appreciate the precision that you use when you say:
But wouldn't you agree that your statement is incomplete? It is absolutely correct that in "GET" in REST provides one of the highest levels of decoupling. However, when actions are involved, I still don't buy the explanation that you give.
When you say something like this:
there is an explicit agreement between the seller and the buyer. "If you do this" "I will consider this bill paid", the payBill action has not magically disappeared, it is intrinsic to the resource because it corresponds to an exact state transition of the bill/invoice. You have simply used HTTP as a communication mechanism, which IMHO, is a perfectly valid things to do. Unlike SOAP you are using a lot more of HTTP to manage the communication, but you are still communicating.I would also argue that If you don't express this agreement explicitly, you are actually strongly coupling the two parties involved.
Now, when you say:
I would really appreciate if you could differentiate human-to-resource and resource-to-resource communications. This is the ambiguity that most people in the REST camp are relying on tell great things about REST, but in resource-to-resource interactions, the benefits are simply not there. I also would like to point out that in practice there are still very few (comparatively) web applications that are 100% REST compliant.Interview Link is not working
by Prajwal Tuladhar,
Your message is awaiting moderation. Thank you for participating in the discussion.
The Full Interview Link is not working...
Re: Interview Link is not working
by Ryan Slobojan,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks for the note - this link has been fixed in the news article.
@Jean
by hernan garcia,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think that the reason why most so called REST applications are not 100% REST compliant (ex: using GET to POST or PUT resources, or passing and action as a parameter in the url resource or the POST load instead of using verbs) is because of lack of knowledge.
This lack of knowledge can be on REST itself, on the tools (language, technologies they are using) or a mix of both.
There is as well a tendency (at least in the MS world) to use the tools the vendor provides in the way the vendor tells you to use them. For example until recently most developers in th .Net camp believed that creating a Web Service was adding and asmx file on their solution.
A lot of them didn't even knew that they could enable GET and POST with a simple edit of the web.config file.(Still not rest but at least make the WS easier to consume from JavaScript for example).
I'm not saying that this is the developers fault at all, but the way they were show how to do things.
I agree with you that the comment about pointing a web server to a REST service make as well send the wrong message and make people believe that REST services are not to be consumed by resources. A REST service is extremely easy to be consumed by a resource, specially because of the flexibility that REST gives you. If you miss the ability to generate client stub (like you do using a WSDL in SOAP) you can take a look at WADL, although only a few REST services use it.
Re: @Jean
by Jean-Jacques Dubray,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hernan:
thanks for your reply. I appreciate how REST works in human-browser-server interactions, i.e I can appreciate the global scope of URIs, the wonders of the uniform interface and I can appreciate that the benefit of "REST being limited to the client being told what to do next by the current state of where they are now".
That being said, I am also one of the editors of the OASIS ebBP specification, the first one to offer a web service assembly capability and a co-author of one of the earlier versions of the SCA specification which also offers an assembly mechanism. I can assure you that "generating client stubs" is the least of my concerns for the very good reason that I am a SOA guy. SOA is about reuse. A service is a reusable IT asset, a SOA is an architecture which supports building solutions from existing assets. My assets are not "generated" they are already built. I assemble them to support new units of work. REST as it is defined by Roy or by a small community of people does not support an "assembly mechanism" precisely because of the "uniform interface" constraint. True resources inter-act with each other, their interactions are not always mediated by humans. "Machines" can't use REST alone, they can't use a uniform interface to interact.