I started writing services in websites back in the .NET 1.0 days. Originally I was doing just POX (Plain Old XML) services in a very crude way so we could get the job done for our internal systems back in the early 2000's.
This means I've been through the "new tech" crazy with services for a long time. I've spent much of the last year digging into different tech for services to interact with websites (though many of the same issues are for rich clients and IoT). I'm not done and don't know how right my assumptions are yet, but I thought I'd try to start a conversation.
So as some of you know, I’ve spent a lot of the last year working on a web project. I’ve been using ASP.NET MVC3 and it’s going well. I am at the point where we are creating the mobile apps. I service them, I need an API (which will eventually be available as a public API too). I had started creating using MVC and simple routes but I was urged to look at the new Web API stack that is installed with the new ASP.NET MVC4 installer.
If you're a regular reader of my blog, you'll probably remember my pithy blog post where I stated that "It all depends..." to the question "Which Data Access Should I Use for Silverlight 3?" The reality is that much like the similar question I am confronted with at user groups for the past decade ("What data access should I use in my .NET app?"). The reasons for picking a strategy are wide and varied so I will not try to analyze all possible outcomes, but I think the different strategies need to be explained better.
The three major candidates in Silverlight 3 are Web Services (WCF/ASMX), ADO.NET Data Services and RIA Services. In any situation, any of these will work. But they are suited to different styles and requirements. Here's the abridged differences between the stacks:
The goal of Project Niagara is to democratize the validation support. The project wants to help developers add validation support to ADO.NET Data Services as well as Web Services in Silverlight. In addition, it has the goal of allowing multiple ways to supply the validation metadata to the different data access strategies. As it is my opinion that there are scenarios where attributes are not the best idea.
If you missed me in Bulgaria's DevReach conference, the video of my Silverlight Data Access talk is now available. The original talk's description was:
After reading Rocky's blog about DataSets and Web Services, I am afraid that he is falling into the same trap that other's have (including the emminently qualified Tim Ewald) with respect to DataSets. DataSets work well in Web Services but not by default. As I mentioned in:
When I first read the SOAP specification I could not decide whether it was meant to be a replacement for DCOM/RPC or whether it was a messaging protocol. I loved the fact that the ligua franca of SOAP was XML. But at the same time, Section 5 supported the RPC view of SOAP. Unfortunately this section seemed to just confuse the issue between the RPC world and the document/literal world.
In a great MSDN Article, Tim Ewald argues against support for Section 5 support. I guess I haven't been keeping up, but I am excited to hear that Section 5 support is now optional in SOAP 1.2 specification. Yeah...but will Section 5 really ever die?
I just attended the second day of Chris Sells' and Tim Ewald's great Web Services DevCon East and had a great time. Yasser Shohoud gave a wonderful talk on "The Right Way to Build Web Services". He echoed something I have been thinking of for some time. Sure, I didn't want to learn how to write WSDL. At the same time I know that the WSDL that is generated by using the '?wsdl' syntax of ASP.NET's .asmx files does not let me design the interface first. I changed my mind and learned to write WSDL. WSDL really isn't too difficult to write. It is too bad that we cannot disable the ?wsdl syntax and just use a static WebService.WSDL URL to have our customer's get our WSDL files.
My natural inclination is still influenced by my days developing COM components in ATL. I want to define the interface up front like we did with IDL. In the early days of ATL, I had been doing MFC work and did not want to hand-code my own IDL either. You would think I would have learned by now that by starting with interface is the better development model. By writing our own WSDL we can define our interfaces (both the calling convention and the schema of the message) and run WSDL.exe to build a skeleton class for us to implement the service.
Why is everyone so down on using DataSets in .NET Web Services? Sure, I’ll admit that using DataSets directly as Web Service parameters are indeed a problem. But why throw the baby out with the bath water?
For the uninitiated, DataSets are a problem as Web Service parameters because XML that is automatically generated as the parameter is a DiffGram of the DataSet. Unfortunately DiffGrams are simply not interop-friendly. At the end of the day the obvious use of DataSets in .NET Web Services are simply a bad idea.
|Vue.js by Example|
|Bootstrap 4 by Example|
|Intro to Font Awesome 5 (Free Course)|
|Designing RESTful Web APIs (new)|
|Building an API with ASP.NET Web API|
|Building an API with ASP.NET Core|
|Building a Web App with ASP.NET Core, MVC6, EF Core, Bootstrap and Angular|
|Less: Getting Started|
|Application Name||WilderBlog||Environment Name||Production|
|Application Ver||v4.0.30319||Runtime Framework||x86|
|App Path||D:\home\site\wwwroot\||Runtime Version||.NET Core 3.0.0|
|Operating System||Microsoft Windows 10.0.14393||Runtime Arch||X86|