

Introduction to ASP.NET Web API - fekberg
http://blog.filipekberg.se/2012/03/19/introducing-the-asp-net-web-api/

======
axefrog
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.

~~~
ams6110
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.

------
arethuza
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.

~~~
cek
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.

------
jinushaun
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!

~~~
Todd
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.

------
ttran
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.

~~~
darrenkopp
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.

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

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

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

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

------
meow
This looks very noisy after using NancyFx (<https://github.com/NancyFx/>)

~~~
Todd
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.

~~~
liquid_x
Still a lot more bloat in web api than nancy

