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

Während die Umstellung von ASP.NET WebAPI auf .NET Core noch überschaubar ist, macht die Umstellung WCF-basierter Webservices auf .NET Core viel Arbeit.

Lesezeit: 9 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 9 Beiträge
Umstieg auf .NET Core, Teil 4: SOAP- und REST-Webservices umstellen

(Bild: Piyawat Nandeenopparit/Shutterstock.com)

Von
  • Dr. Holger Schwichtenberg
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:

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.

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.

Proxy-Generierung für Googles RPC-Dienste und WebAPIs mit OpenAPI-Metadaten in Visual Studio 2019 (Kontextmenüeintrag "Add Connected Services") (Abb. 1)

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.