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.

Ever get perplexed when designing your API for the web? My new course is now available on PluralSight that helps you design your API. The course covers:

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.

Url: http://niagara.codeplex.com

Url: http://oreilly.com/catalog/9780596523091/index....

Url: http://www.silverlightshow.net/shows/Consuming-...

Url: http://www.lhotka.net/WeBlog/CommentView.aspx?g...

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.

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.

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?