Die Slides zu meinem ASP.NET Web API Round-Up bei der Online-Usergroup finden sich hier:

Samples finden sich hier.

Die Aufzeichnung ist ebenfalls online:

ASP.NET Web API Round Up from .NET Online User Group on Vimeo.

Today Microsoft presented and released ASP.NET MVC 4 Beta at  TechDays Belgium.

To me personally the most important improvement is the integration of the WCF Web API into the ASP.NET Stack.

One of the main reason for merging both has been the question “why two frameworks from Microsoft which allow us to create ReSTful APIs?”

Thus, the ASP.NET MVC developers now get the goodies from the WCF Web API.

Everything new?

Let’s take a look at how we do things now.

The most important change is the implementation of our own APIs themselfes:

Until now, we did it this way using WCF Web API::

Using ASP.NET Web API it looks like this:

As you can see, you’re implementing now a Controller also for APIs. But it does not derive from Controller as MVC Controllers do and there’s no common base class at all.

When looking at our code, you may ask: how does Web API know, which HTTP Methods should be mapped to which class methods?

ASP.NET Web API now uses Convention over Configuration already known from ASP.NET MVC, thus naming of the class method declares the HTTP method being used.

And by the way: Convention over Configuration also takes effect at the controllers: Controllers have to be inside the Controllers folder known from MVC.

Convention over Configuration…but

…there’s still a little piece of confiugration left. Let’s head over to the Global.asax.cs. That’s the place where ASP.NET Web API is (still) configured.

The only mandatory option that needs always to be configured, is the assignment of a route inside the route tables to our API controllers.

Here is another improvement: ASP.NET Web API now uses ASP.NET MVC Routing. But be careful: Route definitions don’t use MapRoute but MapHttpRoute instead:

The difference between default MVC route and the default Web API Route is that the action is not contained in our URIs (that’s were the convention comes in).

Thus, our API is available here:

http://localhost/api/customers

GET /customers/id, PUT, POST etc. work analogous.

If you want to implement more than one GET method on your web api class, you simply activate the action in you route definition:

Dependency Injection

Dependency Injection still works, of course - shown here using LightCore.

To give and receive...

Certainly, the improvements did not only come from WCF Web API to ASP.NET Web API, but also from ASP.NET MVC, e.g. Model Binding and Validation.

To use Validation you can use the already known Annotations like [Required] etc.:

To get it working, we need an ActionFilter:

The ActionFilter validates the incoming model (e..g. from POST) and creates a JSON object if there were  validation errors and sends them back to the client with a HTTP 400 (Bad request) status code.

At the client side we’re utilizing the response using jQuery AJAX POST:

Of course, on the client side it is necessary to include jQuery unobstrusive Validation Scripts and setting the HTML attributes:

ASP.NET Forms authentication now also is supported out of the box, but this will be part of another blog post.

Hosting

Besides the well known IIS Hosting it is now also possible to self host Web API inside your own process (which is not new for WCF but MVC):

In order to get self hosting working, System.Web.Http.SelfHost needs to be referenced.

That’s it for now to give you a short overview.

Microsoft hat heute auf den TechDays in Belgien die lang erwartete ASP.NET MVC 4 Beta vorgestellt und auch öffentlich zum Download bereitgestellt.

Die für mich wichtigste Neuerung ist die Integration der bisherigen WCF Web API in den ASP.NET Stack.

Einer der Hauptgründe für die Zusammenführung der beiden Projekte war die bisher berechtigte Frage nach der Koexistenz von zwei Frameworks von Microsoft, die beide das Erstellen von ReSTful Services erlauben - namentlich das bereits vorhandene ASP.NET MVC sowie die eben erwähnte und zum damaligen Zeitpunkt neu entwickelte WCF Web API.

Somit kommen den ASP.NET MVC Entwicklern nun die bereits implementierten Goodies der WCF Web API zugute.

Alles neu macht…der ApiController

Wie sieht das Ganze nun in der Praxis aus?

Die wichtigste Änderung ist die Implementierung einer API (oder auch Services, je nach Sprachgebrauch):

Bisher implentierte man eine API folgendermaßen:

Mit der ASP.NET Web API geschieht dies nun etwas anders:

Wie man sieht, wird nun für die APIs ebenfalls ein Controller implementiert, der jedoch nicht von Controller erbt, sondern von ApiController. Es gibt auch keine gemeinsame Basisklasse mit Controller.

Wenn man das Beispiel ansieht, taucht natürlich sofort eine weitere Frage auf: woher “weiß” die ASP.NET Web API, welches die Methoden für GET, POST, PUT etc. sind?

Hier greift nun das von ASP.NET MVC bekannte Prinzip “Convention over Configuration”, d.h. das Naming der Methode in der Klasse der API bestimmt auch deren HTTP Methode.

Übrigens gilt Conventention over Configuration auch bei den Controllern: Die API-Controller müssen ebenfalls im Controller-Ordner von ASP.NET MVC liegen.

Convention over Configuration…aber

…ein wenig Konfiguration gibt es doch noch - wechseln wir deshalb zur Global.asax.cs. Konfiguriert wird die ASP.NET Web API nach wie vor dort.

Die einzige Option, die grundlegend nötig ist, ist die Zuweisung einer Route in den Route Tables zu den ApiControllern.

Auch hier gibt es eine positive Neuerung: ASP.NET Web API nutzt nun das ASP.NET MVC Routing, allerdings erfolgt die Route-Definition nicht über MapRoute, sondern über MapHttpRoute:

Der Unterschied zur Default-Route von MVC ist der, dass die Action nicht explizit in der URI vorkommt (hier greift die genannte Konvention).

Somit ist unsere CustomersApi unter

http://localhost/api/customers

verfügbar - GET /customers/id, PUT, POST etc. funktionieren analog.

Möchte ich nun z.B. mehrere Get-Methoden implementieren, kann ich das über das Routing leicht ändern, indem ich einfach die Action einfach wieder mit in die Route aufnehme:

Dependency Injection

Natürlich funktioniert auch weiterhin Dependency Injection, hier wieder am Beispiel von LightCore.

Geben und nehmen...

Natürlich sind nicht nur Neuerungen der WCF Web API in die ASP.NET Web API eingeflossen, sondern Web API profitiert auch von ASP.NET MVC Features, z.B. dem Model Binding und der Validierung.

Für die Validierung können die gewohnten Annotations wie [Required] etc. verwendet werden:

Um die Validierung ans Arbeiten zu bekommen, ist nun noch ein ActionFilter nötig:

Der ActionFilter validiert das Model, welches z.B. per POST gesendet wurde und erzeugt im Fehlerfall ein JSON-Objekt, welches die Auflistung der Fehler enthält. Diese werden mit einem HTTP Status Code 400 (Bad Request) zurück an den Client geschickt.

Auf der Client-Seite werten wir das Ganze mit jQuery im POST-Request aus:

Voraussetzung ist natürlich das Einbinden der jQuery unobstrusive Validation Scripts und das Setzen der Entsprechenden Attribute im HTML-Code:

Ebenfalls unterstützt ist nun FormsAuthentication, dies wird allerdings Gegenstand eines eigenen Blog Posts sein.

Hosting

Neben dem bekannten Hosting in IIS (Express) ist es auch möglich, Web API in einem eigenen Prozess zu hosten:

Damit SelfHost funktioniert, muß System.Web.Http.SelfHost referenziert sein.

Das soll es als kurzer Überblick von meiner Seite zunächst gewesen sein.

Legacy Code Kata

Nachdem wir in den vergangenen Dojos immer auf der grünen Wiese angefangen haben, werden wir es in diesem Dojo mit einer existierenden Code Basis zu tun haben.

Wie so oft in der Realität, wird es auch hier die Aufgabe sein fremden Code zu erweitern. Trotzdem soll natürlich sicher gestellt sein, dass bestehende Funktionen immer noch wie erwartet funktionieren.

Ziel ist auch dieses mal wieder die Vertiefung der Fertigkeiten in der Zusammenarbeit als Team, Anwendung von TDD, Erkennen von Refactoring Patterns durch Babysteps und natürlich der Erfahrungsaustausch mit anderen Entwicklern.
Ansonsten gelten die üblichen Rahmenbedingungen:

• Lockere Atmosphäre
• Spaß am Coden
• Spaß mit gleichgesinnten Entwicklern haben
• Offen sein für Neues
• CleanCode
• TDD
• .NET oder auch jede andere Sprache (bitte Notebook mit entsprechender IDE mitbringen)

Das Mitbringen von Notebooks ist erwünscht, da wir uns in mehrere Teams aufteilen werden. Zumindest sollte eine Entwicklungsumgebung (Visual Studio, Eclipse, etc. ) installiert sein. Weitere Tools (NUnit, RhinoMocks, CodingDojoHelper, etc.) können wir dann gerne vor Ort verteilen.

Externe Tastaturen haben sich auch als sehr hilfreich erwiesen.

Anmeldung via XING.

Location:

DJK-Ost
Friedrichstaler Allee 52
76131 Karlsruhe

Beginn:
Di, 13.03.2012, 18:00

In Single Page Applications verwendet man häufig Hash-Bang Urls (was das ist, hat Robert hier beschrieben).

Setzt man nun anstelle des üblichen HomeControllers, der die Startseite (üblicherweise die Index View) rendert, eine statische default.htm Datei ein, will man natürlich die Hash-Bang Urls möglichst elegant und wie z.B. von twitter gewohnt in diesem Stil darstellen:

http://meineseite/#!/machwas

Durch die Verwendung der default.htm mit aktiviertem Default-Controller, müßte man das ganze allerdings so darstellen:

http://meineseite/default.htm#!/machwas

Leider funktioniert

http://meineseite/#!/machwas

zunächst nicht mehr (es erscheint die Index-Seite des HomeControllers oder ein 404, falls man den HomeController bereits gelöscht hat).

Der Grund liegt in den Route-Definitionen, die per Default in der Global.asax.cs definiert sind, genauer in der Definition eines Default-Controllers:

Entfernt man die Definition des Default Controllers

funktioniert der Aufruf von

http://meineseite/#!/machwas

wie gewünscht.

Natürlich kann man auch die Index-View des HomeControllers als Startseite für eine Single Page Application verwenden, was ich persönlich aber nicht (mehr) mache.