REST vs SOAP/RPC?

Question

I just looked at this technology called REST and was surprised to find that its being positioned against SOAP/RPC.

Let me talk specifically about SQL Server Data Services. If data that resides in SQL Server is exposed directly using REST or even SOAP, we'll always have corrupt DBAs, i.e hackers posing as DBAs, that manipulate that data in many ways before it is exposed. It is imperative that a middle tier exists between the UI and any data store, since the validation of business logic that comes with bridging those middle tiers over the Internet is vital to rid the planet of corruption. Without a middle tier, we can't bridge the validation logic that kicks in by bridging middle tiers, thus losing the opportunity to build an applications backbone over the Internet that is devoid of human intervention, and hence, corruption. And corruption exists everywhere on the planet.

SOAP works across all software platforms, and I'm sure REST can be used as well. But, we absolutely need an applications backbone over the Internet to validate all commerce. Directly accessing data in data stores such as SQL Server would only cause more confusion, and promote more corruption.

Cheers.

Answer 1

The SSDS service does not expose the SQL Server data store directly through REST or SOAP.  There is a substantial midle tier between the backend storage and the REST and SOAP heads of the service.  

There is a presentation on the architecture of SSDS that explains some of the details:

http://sessions.visitmix.com/?selectedSearch=SQL%20Server%20Data%20Services&searchPlink=true

---

Tonyp

Answer 2

The middle tier has to be positioned in front of the REST/SOAP heads of SSDS.

Here's my point:
As I understand it, there are all kinds of data stores in an enterprise. There may be SQL Server data stores, Exchange Server data stores, BizTalk, and external data stores such as MySQL, Oracle, DB2 and others. And if what I've read about them is right, all of those technologies can host Web Services.

The SQL Server proponents in the enterprise are going to have to fight an uphill battle with the sys admins of all those other data stores that's going to be about positioning SSDS as the head of all those data stores. The outcome of this battle will take a long time to materialize, if ever. Its more likely that all those sys admins will expose their data to the Internet using their own Web Services front end. And that means that you'll have multifaceted access to all kinds of sensitive information in the enterprise, which implies that you'll have to develop all kinds of strategies to defend all those access points.

Its better to strategically place a WCF front end that coalesces information from all those data stores so that you have a single access point to defend; its all about reducing/minimizing the attack surface. Other platforms like Java, Ruby, etc. can talk to this surface using SOAP. I haven't read much about REST, but if it can bridge platforms it can be used to talk to your WCF front end as well.

One purpose of SOAP is to bridge platforms, so it may not necessarily have to be positioned against REST if all REST does is provide a friendly way to expose the business logic in an enterprise. SOAP is more about interoperability across platforms so that code developed using Java/.NET/C++, etc. can invoke methods on each other. Can REST facilitate this as well?

By the way, there's a typo in my original post in this thread - it should be: Without a middle tier, we can't deliver the validation logic that kicks in by bridging middle tiers, thus losing the opportunity to build an applications backbone over the Internet that is devoid of human intervention, and hence, corruption.

I can see why SQL Server proponents might want to host all business logic within the enterprise on SQL Server, but that kind of thinking looks very small minded when you look at the broader landscape.

I hope SSDS won't hold anything back.

Answer 3

 
Can you explain what you mean by the following:

"The SQL Server proponents in the enterprise are going to have to fight an uphill battle with the sys admins of all those other data stores that's going to be about positioning SSDS as the head of all those data stores."

SSDS is not a product that you can buy and deploy inside your enterprise as a front-end to any database.  SSDS is a service that you can subscribe to and use for storing data.  You can use SOAP to access the service to create, delete, update, get and query data entities.

---

Tonyp

Answer 4

You really want me to look at that URL you posted, don't you?

Here's what I meant:
What's to prevent SSDS proponents from wanting to create, delete, update, get and query data in all those other data stores from the middle tier that you were talking about?

Answer 5

 
What will prevent people from wanting to,   OR  being able to use SSDS middle tier to create an entity in one of the other databases in your company is that SSDS is a service that runs inside of Microsoft data centers.  The SSDD front-end, mid-tier and the back-end all run inside of Microsoft.  Microsoft runs the service and the subscribers use it.  The subscribers can only send valid requests to the SSDS service and receive responses from the service.



 

---

Tonyp

Answer 6

That's good. So, Microsoft is not cutting itself off at the head by promoting all kinds of access technologies to middle tier services that would compete with WCF.

I think I like SSDS.

Thanks.

Answer 7

SPEnthusiast said:

That's good. So, Microsoft is not cutting itself off at the head by promoting all kinds of access technologies to middle tier services that would compete with WCF.

I think I like SSDS.

Thanks.

Is it possible you were confusing SSDS and ADO.Net Data Services (aka Astoria)? Astoria exposes RESTful heads over a company's databases. Those heads are hosted by those companies, therein lies the big difference between Astoria and SSDS.

-Jamie

---

http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomson

Answer 8

REST can be implemented in .NET with WCF.  In fact, ADO.NET Data Services ("Astoria") does just that.

We don't believe that REST and SOAP are at odds but rather are complimentary technologies that each have their own place.  Our goal is to make it simple for you to implement web services easily with WCF whether they are REST or SOAP.

Ron Jacobs
WCF/WF Evangelist

---

Ron Jacobs host of ARCast http://www.arcast.net