Umstieg auf .NET Core, Teil 4: SOAP- und REST-Webservices umstellen

Inhaltsverzeichnis

Das klassische .NET Framework bietet vier Arten von Verteilungstechniken an:

• .NET Remoting: ein proprietäres Protokoll von Microsoft
• ASP.NET Webservices (ASMX): SOAP-basierte Webservices
• Windows Communication Foundation (WCF): eine Bibliothek für unterschiedliche Transportprotokolle (z.B. TCP, HTTP, HTTPS, MSMQ, Named Pipes), Formate (bspw. SOAP, XML, JSON und ein proprietäres Binärformat) und Kommunikationsmuster (unidirektional, bidirektional, Duplex) sowie verschiedene Sicherheits- und Zuverlässigkeitsverfahren
• ASP.NET WebAPI: Dienste im REST-Stil mit HTTP/HTTPS und JSON oder XML

Umstieg auf .NET Core

In dieser fünfteiligen Artikelserie geht Holger Schwichtenberg der grundsätzlichen Frage nach, ob Organisationen, die zum Teil schon seit Anfang der 2000er Jahre mit dem klassischen .NET Framework entwickeln, ihren bestehenden Programmcode nun auf .NET Core umstellen sollten. Ist die Entscheidung für eine Migration gefallen, dann gilt es, eine Reihe von Herausforderungen zu meistern:

• Migrieren oder nicht migrieren?
• Desktop-Anwendungen mit WPF und Windows Forms umstellen
• ASP.NET-Webserveranwendungen umstellen
• SOAP- und REST-Webservices umstellen
• Datenzugriff auf .NET Core umstellen

Heute stark verbreitet sind nur noch die beiden letztgenannten, wenngleich man immer noch einzelne Projekte mit .NET Remoting und ASMX findet. Das war auch insofern kein Problem als das klassisches .NET Framework von Version 1.0 (Jahr 2002) bis Version 4.8 (Jahr 2019) hinsichtlich der Funktionalität stabil blieb.

Mit dem Umstieg auf .NET Core beziehungsweise den für November 2020 angekündigten Nachfolger .NET 5.0 (ohne Core im Namen) kommt es zu – teils erheblichen – Brüchen für die Nutzer von Webservices.

WebAPI Core

In .NET Core gibt es mit ASP.NET Core WebAPI einen direkten Nachfolger des klassischen ASP.NET WebAPI. Wie bisher erfolgt die Serialisierung mit JSON oder XML – andere Serialisierer sind implementierbar. Für den Transport gibt es aber nur HTTP oder HTTPS. Für Metadaten in der OpenAPI-Spezifikation (ehemals "Swagger") stehen mit Swashbuckle und NSwag direkt zwei ergänzende Open-Source-Projekte zur Auswahl. Microsoft unterstützt die Integration von OpenAPI durch Hilfeseiten und Werkzeuge wie die Proxy-Generierung mit "Add Connected Services" (s. Abb. 1). Alternativ lassen sich eigenständige Code-Generatoren wie NSwagStudio nutzen.

Zwischen dem klassischen ASP.NET WebAPI (aktuelle Version 5.2.7 vom 29. November 2018) und ASP.NET Core WebAPI (aktuelle Version 3.1.1 vom 14. Januar 2020) sind einige Verhaltensunterschiede bei der Implementierung von Controller-Klassen und Aktionsmethoden sowie der Parameterbindung zu beachten:

	Klassisches ASP.NET WebAPI 5.x	ASP.NET Core 1.x und 2.0	ASP.NET Core seit 2.2
Entwicklung	Eigenständiges Produkt	Teil von ASP.NET Core MVC	Teil von ASP.NET Core MVC
Basisklasse für die eigene Controller-Klasse	ApiController	Controller	ControllerBase
Annotation	Keine	Keine	[ApiController]
Komplexe Typen aus Query String	[FromUri]	Standard	[FromQuery]
Komplexe Typen aus Form Data	-	[FromForm]	[FromForm]
Komplexe Typen aus JSON-Body	Standard	[FromBody]	Standard
Validierung	Annotation + ModelState.IsValid()	Annotation + ModelState.IsValid()	Annotation + Automatische Fehlermeldung
Rückgabetypen	HttpResponseMessage oder IHttpActionResult oder T	ActionResult<T> oder IActionResult	ActionResult<T> oder IActionResult oder T

Wie bei der Umstellung von WPF- und Windows Forms-Anwendungen (Teil 2 der Serie) und ASP.NET-Websites (Teil 3 der Serie), beginnt die Umstellung von ASP.NET WebAPI zu ASP.NET Core mit dem Anlegen eines neuen .NET Core-Projekts. Den Startcode und die Konfiguration der Anwendung muss man neu erstellen, die Controller und ergänzende Klassen kann man in das neue Projekt kopieren.