REST vs SOAP/RPC? I just looked at this technology called REST and was surprised to find that its being positioned against SOAP/RPC.<br><br>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.<br><br>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.<br><br>Cheers.<br>© 2009 Microsoft Corporation. All rights reserved.Wed, 02 Jul 2008 18:49:15 Ze4d352a4-e793-4cf4-8f27-0add1d155d73http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#e4d352a4-e793-4cf4-8f27-0add1d155d73http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#e4d352a4-e793-4cf4-8f27-0add1d155d73SPEnthusiasthttp://social.msdn.microsoft.com/Profile/en-US/?user=SPEnthusiastREST vs SOAP/RPC? I just looked at this technology called REST and was surprised to find that its being positioned against SOAP/RPC.<br><br>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.<br><br>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.<br><br>Cheers.<br>Sat, 14 Jun 2008 19:14:58 Z2008-06-14T19:14:58Zhttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#5438d523-e4b8-4e62-b3ff-772192445336http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#5438d523-e4b8-4e62-b3ff-772192445336Tony Petrossianhttp://social.msdn.microsoft.com/Profile/en-US/?user=Tony%20PetrossianREST vs SOAP/RPC?<p></p> <p>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.  </p> <p>There is a presentation on the architecture of SSDS that explains some of the details:<br></p> <p id=""><a href="http://sessions.visitmix.com/?selectedSearch=SQL Server Data Services&amp;searchPlink=true">http://sessions.visitmix.com/?selectedSearch=SQL%20Server%20Data%20Services&amp;searchPlink=true</a><br><br></p><hr size="1" align="left" width="25%">TonypSun, 15 Jun 2008 05:47:28 Z2008-06-15T05:47:28Zhttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#33412395-03ee-40db-abe7-e9227105ab00http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#33412395-03ee-40db-abe7-e9227105ab00SPEnthusiasthttp://social.msdn.microsoft.com/Profile/en-US/?user=SPEnthusiastREST vs SOAP/RPC?<p>The middle tier has to be positioned in front of the REST/SOAP heads of SSDS.<br><br>Here's my point:<br>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.<br><br>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.<br><br>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.<br><br>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?<br><br>By the way, there's a typo in my original post in this thread - it should be: Without a middle tier, we can't <strong><em>deliver </em></strong>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.<br><br>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.<br><br>I hope SSDS won't hold anything back.<br><br><br></p>Sun, 15 Jun 2008 07:22:50 Z2008-06-15T07:26:46Zhttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#dcbdc984-0e47-4d7d-87e2-df37cecff58ehttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#dcbdc984-0e47-4d7d-87e2-df37cecff58eTony Petrossianhttp://social.msdn.microsoft.com/Profile/en-US/?user=Tony%20PetrossianREST vs SOAP/RPC?<p dir=ltr style="margin-right:0px"> <br>Can you explain what you mean by the following:<br><br><em>&quot;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 <font style="background-color:#ffff66">positioning SSDS as the head of all those data stores</font>.&quot;<br><br></em>SSDS is not a product that you can buy and deploy inside your enterprise as a front-end to any database.  SSDS is a <strong>service</strong> 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.<br><br></p><hr size="1" align="left" width="25%">TonypMon, 16 Jun 2008 05:19:59 Z2008-06-16T05:19:59Zhttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#bde7779c-5096-479f-b270-1e09bae68536http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#bde7779c-5096-479f-b270-1e09bae68536SPEnthusiasthttp://social.msdn.microsoft.com/Profile/en-US/?user=SPEnthusiastREST vs SOAP/RPC? You really want me to look at that URL you posted, don't you?<br><br>Here's what I meant:<br>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?<br><br>Mon, 16 Jun 2008 12:01:05 Z2008-06-16T12:01:05Zhttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#eb37486c-13fc-453e-b1dc-51b8fe5256cchttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#eb37486c-13fc-453e-b1dc-51b8fe5256ccTony Petrossianhttp://social.msdn.microsoft.com/Profile/en-US/?user=Tony%20PetrossianREST vs SOAP/RPC? <br>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.<br><br><br><br>  <br><br><hr size="1" align="left" width="25%">TonypMon, 16 Jun 2008 17:49:36 Z2008-06-16T17:49:36Zhttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#bde6c414-ed36-4b6c-b0b7-f883e165049chttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#bde6c414-ed36-4b6c-b0b7-f883e165049cSPEnthusiasthttp://social.msdn.microsoft.com/Profile/en-US/?user=SPEnthusiastREST vs SOAP/RPC? 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.<br><br>I think I like SSDS.<br><br>Thanks.<br>Mon, 16 Jun 2008 23:42:36 Z2008-06-16T23:42:36Zhttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#252e1b5f-74bb-4190-97d6-79255220448ahttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#252e1b5f-74bb-4190-97d6-79255220448aJamie Thomsonhttp://social.msdn.microsoft.com/Profile/en-US/?user=Jamie%20ThomsonREST vs SOAP/RPC?<div class=quote><font class=quoteHeader>SPEnthusiast said:</font> <p>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.<br><br>I think I like SSDS.<br><br>Thanks.<br></p></div><br><br>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.<br><br>-Jamie<br><hr size="1" align="left" width="25%">http://jamiethomson.spaces.live.com/ | http://blogs.conchango.com/jamiethomsonTue, 24 Jun 2008 16:25:22 Z2008-06-24T16:25:22Zhttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#4fe62a8e-801b-4f8d-a165-c204c21d312bhttp://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/e4d352a4-e793-4cf4-8f27-0add1d155d73#4fe62a8e-801b-4f8d-a165-c204c21d312bRon Jacobshttp://social.msdn.microsoft.com/Profile/en-US/?user=Ron%20JacobsREST vs SOAP/RPC? REST can be implemented in .NET with WCF.  In fact, ADO.NET Data Services (&quot;Astoria&quot;) does just that.<br><br>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.<br><br>Ron Jacobs<br>WCF/WF Evangelist<br><hr size="1" align="left" width="25%">Ron Jacobs host of ARCast http://www.arcast.netTue, 24 Jun 2008 22:35:55 Z2008-06-24T22:35:55Z