New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Interview: Pete Lacey on REST and Web Services
Posted by Stefan Tilkov on May 13, 2008
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).
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
Loose Coupling
by
Jean-Jacques Dubray
Posted
Interview Link is not working
by
Prajwal Tuladhar
Posted
Re: Interview Link is not working
by
Ryan Slobojan
Posted
@Jean
by
hernan garcia
Posted
Re: @Jean
by
Jean-Jacques Dubray
Posted
-
Pete:
I really appreciate the precision that you use when you say:
"I can "GET" it and maybe something interesting will come from that, and it may be all the information I need. So properly designed RESTful system is dramatically loosely coupled, whereas a properly designed SOAP WS-* based system is unfortunately tightly coupled and all you can do is your best effort to avoid more tightly coupling than necessary."
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:
"what I have is some kind of payment resource that I would post my check to."
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:
"Not only is there a series of resources out there that you can get – you wouldn't say this to your business, you would say "Just put this in your browser", and a web application might come up, and remember it's possible to have a web application that is entirely one hundred percent RESTful."
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. -
The Full Interview Link is not working...
-
Thanks for the note - this link has been fixed in the news article.
-
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. -
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.
5 comments
Watch Thread Reply