When it comes to integrating SSRS into Apps, what's the difference between "ReportViewer controls for Visual Studio" and "URL access"?

Question

ReportViewer needs to make calls to the SSRS Server via SOAP requests I believe. It is basically a window into the SSRS site and has all the functionality in the services available visually at once. The viewer usually presents the report in a format like:

http:// (server)/Reports/Pages/Report.aspx?ItemPath=%2f(ReportName)

The URL access is generally the webservice of SSRS doing the work for you directly with commands given to it directly. It is important to note that I believe the web service does all the work for both but the site access also has visual studio on the host and client location also doing some after market CSS rendering and other things from their default locations. The Webservice is just rendering the report and potentially the header where the parameters are. You can even pass in parameters in the URL if you know what you are doing with SSRS. However this does not present a usable object for rendering except in a browser.

EG: say I have a report that takes two parameters: A 'Start' datetime and an 'End' datetime. I can call the web service and render the report and input the parameters at the same time. I could host this in my own browser viewer, but not really do much with the object without developing something else to consume it.

http:// (server)/ReportServer/Pages/ReportViewer.aspx?%2f(ReportName)&rs:Command=Render&Start=11/01/2012&End=1/1/2013

You can also do your own calls in .NET with talking to the SSRS web services or creating your own proxy classes. This is for applications when you want to render in custom formats with events triggered from potentially an application that is not on a set schedule or you want to decouple from the SSRS site and maintain your own settings without relying on the server being the decider of when things happen.