I'd like to propose a ban on all programming tutorials which utilise screenshots of a given IDE's magic, visual tools as an integral, required step in the process. I develop with Visual Studio myself, but that doesn't mean everybody does and it doesn't help to further anybody's understanding of a given process when the foundations are glossed over by drag-and-drop/point-and-click programming. Instead, the author should specify what references the new project requires and why and optionally display the screenshots as a supplement.

The best book I've read about .NET programming was Microsoft .NET for Programmers by Fergal Grimes. Though a bit out of date now (published in 2002) rather than starting off with a Visual Studio project you write some C# code in Notepad and compile from the command line with csc. He takes you through the process of manually wiring an ASP.NET page and codebehind file, etc. all without an IDE.

Later on when you start using the IDE you have a MUCH better understanding of what's happening behind the scenes.

I'm not sure if anything like this book has been written for later versions of the .NET platform, as I haven't touched .NET since about 2008.

I think banning them is a little too harsh. But you are right -- you don't get it until you can do it without the tools (then you do it with the tools anyway since you will spend less time that way, at least in most of the cases).

This looks quite nice, but the author should perhaps refrain from calling something a "REST API" just because it uses GET/POST/PUT/DELETE and returns JSON/XML.

Can you provide a specific example in the article (or the technology referenced) where the "REST API" discussed is not actually REST?

I didn't see any, but I'm no expert and I'm trying to learn.

I know this is still a new API, but I really wish there were more in-depth tutorials based on real world use cases. Namely everyone seems to gloss over authentication and cross domain login. Instead of a true publicly accessible independent API, everyone seems to build the website and Web API in the same project. They're one and the same!

Agreed. Getting authentication right when hosting your API on a different subdomain is difficult. You can write an HTTP handler to implement CORS but it's less than optimal if you also want to support Ajax within your app, in addition to normal API usage.

As an alternative, you can implement your API in a different project and host it on a virtual path (e.g., /api). This solves the auth problem, but it poses difficulties under IIS. In particular, your Web.config inherits from the parent Web.config, so sections can be clobbered.

Ultimately, it's easiest to just host your app and your API in the same project. You can implement forms auth (or roll your own cookie auth) so your Ajax requests Just Work (TM) and then implement separate auth (like Basic Auth or OAuth) on just the API controllers to support real API usage.

This is not new, really. This is just a different name for the Controller in ASP.NET MVC model. We've been doing this even with ASP.NET MVC 2, i.e. expose RESTful APIs, or any public functions of our controllers, which return JSON data or any primitive data type.

The process to create a Web API class is identical to the process to create a ASP.NET MVC controller class, that is: - create a class - create public functions - set the route

It's nice make the controller role stand out and have its own name (Web API), however, I feel a bit disappointed if Microsoft touts this as a big feature of the next Visual Studio and .NET Framework.

Yup. Not new at all. MVC has always been able to automatically change it's output based on the Accept header that was passed in on the request. MVC has always been able to be self hosted in something like a console application or windows service so you didn't have to use IIS.

Oh wait, no it doesn't. I guess you could say this is a completely new product that uses a lot of the same patterns as MVC, but ultimately does things very differently.

Please show me where this or a previous version of ASP.NET MVC can be hosted in a console app?

It can't. That was sarcasm. My point was that Web API does a lot of things MVC can't.

Ok, well the article didn't mention non-IIS hosting either unless I missed it.

it's there for Web Api, article may not mention it though.

This looks very noisy after using NancyFx (https://github.com/NancyFx/)

The author left out the most important part, which is the controller. The HTTP methods match controller verbs without requiring any attribute markup. The Get method responds to /controller (all) or /controller/5 (ID of 5), the Post method responds to a POST on /controller, the Delete method responds to DELETE on /controller/5, etc.

It's very elegant at this level. Adding additional methods requires more work, as does managing routing and the other support infrastructure in a more complex application, but it provides a great starting point.

One of the things that isn't great is that they, of necessity, have a different base class. Instead of Controller, it's ApiController. That makes sense. However, the differences pervade the entire stack, down to things like the Request and Response objects, and even AuthorizeAttribute (same class name in a different namespace with different parameters).

All in all, though, it's great. It certainly beats using WCF for simple REST APIs and it beats trying to repurpose MVC to implement an API.

Still a lot more bloat in web api than nancy