Datenpunkte

  • Artikel

Eine neue Option zum Erstellen von OData: Web API

Julie Lerman

Julie LermanMicrosoft .NET-Entwickler konnten OData-Feeds bereits erstellen, als es noch gar keine OData-Spezifikationen gab. Durch die Verwendung von WCF Data Services konnten Sie mithilfe von Representational State Transfer (REST) ein Entity Data Model (EDM) über das Web zur Verfügung stellen. Mit anderen Worten, Sie konnten diese Dienste mittels HTTP-Aufrufe nutzen: GET, PUT, DELETE usw. Als das Framework zum Erstellen dieser Dienste weiterentwickelt wurde (und nebenbei mehrmals umbenannt wurde), hat sich die Ausgabe ebenfalls weiterentwickelt und wurde schließlich in der OData-Spezifikation (odata.org) aufgenommen. Heute gibt es eine Vielzahl von Client-APIs zum Nutzen von OData: .NET, PHP, JavaScript und auch viele andere Clients. Bis vor kurzem konnte jedoch ein Dienst einfach nur mit WCF Data Services erstellt werden.

Bei WCF Data Services handelt es sich um eine .NET-Technologie, die Ihr EDM einfach umschließt („.edmx“ oder ein über Code First definiertes Modell) und dann dieses Modell zum Abfragen und Aktualisieren über HTTP verfügbar macht. Da diese Aufrufe URIs sind (wie zum Beispiel „http://mysite.com/mydataservice/­Clients(34)“), können Sie sogar eine Abfrage von einem Webbrowser oder einem Tool wie Fiddler durchführen. Zum Erstellen eines WCF Data Service bietet Visual Studio eine Elementvorlage, mit der Sie einen Datendienst mithilfe eines Satzes von APIs erstellen können.

Jetzt gibt es auch eine andere Methode zum Erstellen von OData-Feeds, und zwar mithilfe einer ASP.NET-Web-API. In diesem Artikel möchte ich Ihnen eine ausführliche Übersicht über einige der Unterschiede zwischen diesen zwei Methoden vermitteln und erläutern, warum ich eine Methode gegenüber der anderen vorziehe. Ich werde auch einige der Methoden behandeln, bei denen sich die Erstellung einer OData-API von der Erstellung einer Web-API unterscheidet.

Ausführlicher Vergleich zwischen API und Data Service

Ein WCF Data Service ist ein System.Data.Services.DataService, der eine bereits von Ihnen definierte ObjectContext- oder DbContext-Klasse umschließt. Bei der Deklaration der Dienstklasse ist WCF Data Service ein generischer DataService Ihres Kontexts (d. h. DataService<MyDbContext>). Da der Dienst zu Beginn vollkommen gesperrt ist, legen Sie im Konstruktor Zugriffsberechtigungen für DbSets aus Ihrem Kontext fest, den der Dienst verfügbar machen soll. Das ist alles, was Sie tun müssen. Die zugrunde liegende DataService-API übernimmt die übrigen Aufgaben: direkte Interaktion mit Ihrem Kontext sowie die Abfrage und Aktualisierung der Datenbank als Reaktion auf die HTTP-Anforderungen Ihrer Clientanwendung an den Dienst. Es ist auch möglich, einige Anpassungen am Dienst vorzunehmen und z. B. seine Abfrage- oder Aktualisierungslogik zu überschreiben. Aber größtenteils geht es darum, dass die meisten Interaktionen mit dem Kontext vom DataService ausgeführt werden.

Mit einer Web-API können Sie andererseits die Kontextinteraktion als Reaktion auf die HTTP-Anforderungen definieren (PUT, GET usw.). Die API macht Methoden verfügbar, und Sie definieren die Logik der Methoden. Sie müssen dazu nicht unbedingt mit dem Entity Framework oder sogar einer Datenbank interagieren. Es können speicherresidente Objekte vorhanden sein, die der Client anfordert oder sendet. Die Zugriffspunkte erstellen sich nicht ohne weiteres von selbst wie beim WCF Data Service. Stattdessen legen Sie fest, was als Reaktion auf diese Aufrufe geschehen soll. Dies ist der entscheidende Faktor, warum ein Dienst gegenüber einer API bevorzugt wird, um Ihre OData verfügbar zu machen. Wenn Sie größtenteils nur eine einfache Create-, Read-, Update- und Delete-Funktion (CRUD) verfügbar machen möchten, ohne unbedingt viele Anpassungen vornehmen zu müssen, ist ein Datendienst die beste Wahl. Wenn Sie einen Großteil des Verhaltens anpassen müssen, ist eine Web-API sinnvoller.

Mir gefällt es, wie sich Microsoft Integration MVP Matt Milner bei einem Treffen vor kurzer Zeit ausgedrückt hat: „WCF Data Services ist geeignet, wenn Sie mit den Daten und dem Modell beginnen und diese einfach nur verfügbar machen möchten. Eine Web-API ist besser, wenn Sie mit der API beginnen und dann definieren möchten, was sie verfügbar machen soll.“

Schaffen optimaler Voraussetzungen mit einer Standard-Web-API

Denjenigen Benutzern, die über begrenzte Erfahrung mit Web API verfügen, würde ich empfehlen, sich mit den Grundlagen der Web-API vertraut machen, bevor sie den neuen OData-Support in Betracht ziehen. Dann können sie feststellen, wie dieser mit der Erstellung einer Web-API, die OData verfügbar macht, in Zusammenhang steht. Ich zeige Ihnen das hier. Zuerst erstelle ich eine einfache Web-API, die Entity Framework als Datenschicht verwendet, und dann wandle ich sie um, damit die Ergebnisse als OData ausgegeben werden.

Eine Web-API kann als Alternative zu einem Standardcontroller in einer MVC-Anwendung (Model-View-Controller) verwendet werden, und Sie können sie als Teil eines ASP.NET MVC 4-Projekts erstellen. Wenn Sie keine Front-End-Anwendung wünschen, können Sie mit einer leeren ASP.NET-Webanwendung beginnen und dann Web-API-Controller hinzufügen. Den Einsteigern zuliebe beginne ich jedoch mit einer ASP.NET MVC 4-Vorlage, weil diese Gerüstoptionen bieten, die einen Startcode ausgeben. Sobald Sie verstanden haben, wie alles zusammenpasst, ist die beste Methode, mit einem leeren Projekt zu beginnen.

Also erstelle ich eine neue ASP.NET MVC 4-Anwendung und wähle dann bei Aufforderung die leere Vorlage (nicht die Web-API-Vorlage, die für eine stabilere App ausgelegt ist, die Ansichten verwendet und für meine Zwecke übertrieben wäre). Dies ergibt ein Projekt, das für eine MVC-App mit leeren Ordnern für Modelle, Ansichten und Controller strukturiert ist. In Abbildung 1 werden die Ergebnisse der leeren Vorlage mit der Web-API-Vorlage verglichen. Es ist ersichtlich, dass eine leere Vorlage eine wesentlich einfachere Struktur ergibt. Ich muss lediglich ein paar Ordner löschen.

ASP.NET MVC 4 Projects from Empty Template and Web API Template
Abbildung 1: ASP.NET MVC 4-Projekte von einer leeren Vorlage und einer Web-API-Vorlage

Ich brauche den Ordner für Modelle auch nicht, da ich einen vorhandenen Satz von Domänenklassen und eine DbContext-Klasse in einem separaten Projekt zum Bereitstellen des Modells verwende. Anschließend erstelle ich mit den Visual Studio-Tools meinen ersten Controller – einen Web-API-Controller, der mit meiner DbContext-Klasse und den Domänenklassen interagiert, auf die ich in meinem MVC-Projekt verwiesen habe. Meine Modelle enthalten Klassen für Fluggesellschaften, Passagiere, Flüge und einige weitere Arten von fluglinienbezogenen Daten.

Da ich die leere Vorlage verwendet habe, muss ich einige Verweise hinzufügen, um einen Aufruf in die DbContext-Klasse durchzuführen: einen Aufruf in die System.Data.Entity.dll-Datei und einen anderen in die EntityFramework.dll-Datei. Sie können diese beiden Verweise durch Installieren des EntityFramework NuGet-Pakets hinzufügen.

Sie können einen neuen Web-API-Controller genauso erstellen wie einen Standard-MVC-Controller: Sie können in der Projektmappe mit der rechten Maustaste auf den Ordner „Controller“ klicken und „Hinzufügen“ und dann „Controller“ wählen. Wie in Abbildung 2 ersichtlich, verfügen Sie nun über eine Vorlage zum Erstellen eines API-Controllers mit EF-Lese- und Schreibvorgänge. Es gibt auch einen leeren API-Controller. Beginnen wir mit den EF-Lese-/Schreibvorgängen für einen Vergleich mit dem Controller, den wir für OData einsetzen möchten und der ebenfalls Entity Framework verwendet.

A Template for Creating an API Controller with Pre-Populated Actions
Abbildung 2: Vorlage zum Erstellen eines API-Controllers mit vorab ausgefüllten Aktionen

Wenn Sie vorher MVC-Controller erstellt haben, werden Sie feststellen, dass die resultierende Klasse ähnlich ist. Allerdings verfügt dieser Controller über einen Satz von HTTP-Aktionen statt eines Satzes von ansichtsbezogenen Aktionsmethoden, wie „Index“, „Hinzufügen“ und „Bearbeiten“.

Es gibt zum Beispiel zwei Get-Methoden, wie in Abbildung 3 dargestellt. Die erste Methode „Get­Airlines“ hat eine Signatur, die keine Parameter annimmt und eine Instanz von AirlineContext verwendet (von den Vorlagengerüstoptionen als „db“ benannt), um einen Satz von Airline-Instanzen in einer Enumerable-Klasse zurückzugeben. Die andere Methode „GetAirline“ nimmt eine ganze Zahl auf und verwendet diese, um eine bestimmte Fluggesellschaft zu suchen und zurückzugeben.

Abbildung 3: Einige der Web-API-Controllermethoden, die von den MVC-Gerüstoptionen erstellt wurden

public class AirlineController : ApiController
  {
    private AirlineContext db = new AirlineContext2();
    // GET api/Airline
    public IEnumerable<Airline> GetAirlines()
    {
      return db.Airlines.AsEnumerable();
    }
    // GET api/Airline/5
    public Airline GetAirline(int id)
    {
      Airline airline = db.Airlines.Find(id);
      if (airline == null)
      {
        throw new HttpResponseException
          (Request.CreateResponse(HttpStatusCode.NotFound));
      }
      return airline;
    }

Die Vorlage fügt Kommentare hinzu, um zu veranschaulichen, wie Sie diese Methoden verwenden würden.

Nachdem ich einige Konfigurationen für meine Web-API bereitgestellt habe, kann ich sie direkt in einem Browser ausprobieren. Hierzu verwende ich die Beispielsyntax des Ports, den meine App zugeordnet hat: http://localhost:1702/api/Airline. Dies ist der HTTP-GET-Standardaufruf und wird daher zum Ausführen der GetAirlines-Methode von der Anwendung weitergeleitet. Web API verwendet Inhaltsaushandlung, um festzulegen, wie der Resultset formatiert werden soll. Ich verwende Google Chrome als Standardbrowser, der die Ergebnisse so auslöst, dass sie als XML formatiert werden. Die Anforderung des Clients legt das Format der Ergebnisse fest. Internet Explorer sendet zum Beispiel keine spezifischen Headerinformationen in Bezug auf das Format, das es akzeptiert. Daher gibt Web API standardmäßig JSON zurück. Meine XML-Ergebnisse sind in Abbildung 4 dargestellt.

Abbildung 4: Reaktion der Airline-WebAPI auf GET, die in meinem Browser als XML angezeigt wird

<ArrayOfAirline xmlns:i=http://www.w3.org/2001/XMLSchema-instance 
  xmlns="http://schemas.datacontract.org/2004/07/DomainClasses">
    <Airline>
      <Id>1</Id>
      <Legs/>
      <ModifiedDate>2013-02-22T00:00:00</ModifiedDate>
      <Name>Vermont Balloon Transporters</Name>
    </Airline>
    <Airline>
      <Id>2</Id>
      <Legs/>
      <ModifiedDate>2013-02-22T00:00:00</ModifiedDate>
      <Name>Olympic Airways</Name>
    </Airline>
    <Airline>
      <Id>3</Id>
      <Legs/>
      <ModifiedDate>2013-02-22T00:00:00</ModifiedDate>
      <Name>Salt Lake Flyer</Name>
    </Airline>
</ArrayOfAirline>

Wenn ich gemäß der Anleitung der GetAirline-Methode einen ganzzahligen Parameter zur Anforderung „http://localhost:1702/api/Airline/3“ hinzufügen würde, würde nur eine Fluggesellschaft, deren Schlüssel (ID) gleich 3 ist, zurückgegeben werden:

<Airline xmlns:i=http://www.w3.org/2001/XMLSchema-instance
  xmlns="http://schemas.datacontract.org/2004/07/DomainClasses">
    <Id>3</Id>
    <Legs/>
    <ModifiedDate>2013-02-22T00:00:00</ModifiedDate>
    <Name>Salt Lake Flyer</Name>
</Airline>

Wenn ich Internet Explorer oder ein Tool wie Fiddler verwenden würde, mit dem ich die Anforderung an die API explizit festlegen könnte, um zu gewährleisten, dass das Format JSON ist, würde das Ergebnis der Anforderung für „Airline“ mit ID 3 als JSON zurückgegeben werden:

{"Id":3,
  "Name":"Salt Lake Flyer",
  "Legs":[],
  "ModifiedDate":"2013-03-17T00:00:00"
}

Diese Reaktionen enthalten einfache Darstellungen des Fluggesellschaftentyps mit Elementen für jede Eigenschaft: „Id“, „Legs“, „ModifiedDate“ und „Name“.

Der Controller enthält auch eine PutAirline-Methode, die die Web-API als Reaktion auf die PUT-HTTP-Anforderung aufruft. PutAirline enthält Code zur Verwendung von AirlineContext, um eine Fluggesellschaft zu aktualisieren. Es gibt auch eine PostAirline-Methode für Eingaben und eine DeleteAirline-Methode für Löschvorgänge. Diese können in einer Browser-URL nicht veranschaulicht dargestellt werden, aber Sie finden zahlreiche „Erste Schritte“-Dokumente für Web API auf MSDN, Pluralsight und anderen Websites. Daher fahre ich mit der Umwandlung der Web-API fort, sodass ihr Ergebnis gemäß der OData-Spezifikation ausgegeben wird.

Umwandeln der Web-API in einen OData-Anbieter

Nachdem Sie sich nun mit den Grundlagen vertraut gemacht haben, wie Web API zum Bereitstellen von Daten mittels Entity Framework genutzt werden kann, sehen wir uns die spezielle Verwendung von Web API an, um einen OData-Anbieter anhand Ihres Datenmodells zu erstellen. Sie können Ihre Web-API zwingen, Daten im OData-Format zurückzugeben, indem Sie Ihren Controller in einen OData-Controller umwandeln (durch Verwenden einer Klasse, die im ASP.NET- und Web Tools 2012.2-Paket verfügbar ist) und anschließend dessen OData-spezifische Methoden überschreiben. Mit diesem neuen Controllertyp benötigen Sie nicht einmal die Methoden, die von der Vorlage erstellt wurden. Tatsächlich gibt es eine effizientere Methode zum Erstellen eines OData-Controllers. Wählen Sie einfach eine leere Web-API-Gerüstvorlage anstatt die Vorlage, mit der die CRUD-Vorgänge erstellt wurden. 

Für diesen Übergang muss ich vier Schritte ausführen:

  1. Den Controller in einen ODataController umwandeln und dessen HTTP-Methoden implementieren. Hierzu verwende ich eine Verknüpfung.
  2. Die verfügbaren EntitySets in der WebAPIConfig-Datei des Projekts definieren.
  3. Das Routing in WebAPIConfig konfigurieren.
  4. Den Namen der Controllerklasse zur Abstimmung mit den OData-Konventionen pluralisieren.

Erstellen eines ODataController Anstatt direkt vom ODataController zu erben, verwende ich EntitySetController, der vom ODataController abgeleitet wurde und dank zahlreicher virtueller CRUD-Methoden höherwertigen Support bietet. Ich habe NuGet zum Installieren des OData-Pakets der Microsoft ASP.NET-Web-API für die geeigneten Assemblys verwendet, die die beiden Controllerklassen enthalten.

Hier ist der Anfang meiner Klasse, die nun vom EntitySetController erbt und angibt, dass der Controller für den Airline-Typ gilt:

public class AirlinesController : EntitySetController<Airline,int>
{
  private AirlineContext db = new AirlineContext();
  public override IQueryable<Airline> Get()
  {
    return db.Airlines;
  }

Ich habe die Überschreibung für die Get-Methode ausgearbeitet, die „db.Airlines“ zurückgibt. Beachten Sie, dass ich nicht „ToList“ oder „AsEnumerable“ im DbSet der Fluggesellschaft aufrufe. Die Get-Methode muss eine IQueryable der Fluggesellschaft zurückgeben, und genau das macht db.Airlines. Auf diese Weise können die Nutzer von OData Abfragen über diesen Satz definieren, die dann in der Datenbank ausgeführt werden, anstatt sämtliche Fluggesellschaften in den Speicher einzufügen und sie dann abzufragen.

Sie können folgende HTTP-Methoden überschreiben und eine Logik zu diesen hinzufügen: GET, POST (für Einfügungen), PUT (für Aktualisierungen), PATCH (für Zusammenführungen von Aktualisierungen) und DELETE. Für Aktualisierungen verwenden Sie jedoch eigentlich die virtuelle CreateEntity-Methode, um die für eine POST-Methode aufgerufene Logik zu überschreiben. Die virtuelle UpdateEntity-Methode wird für die mit PUT aufgerufene Logik verwendet und die virtuelle PatchEntity-Methode für die Logik, die für den PATCH-HTTP-Aufruf erforderlich ist. Folgende zusätzliche virtuelle Methoden können zu diesem OData-Anbieter gehören: CreateLink, DeleteLink und GetEntityByKey.

In WCF Data Services legen Sie durch Konfigurieren der SetEntitySetAccessRule-Methode fest, welche CRUD-Aktionen pro EntitySet zulässig sind. Mit Web API können Sie jedoch einfach die Methoden hinzufügen, die unterstützt werden sollen, und die Methoden ausschließen, auf die die Nutzer keinen Zugriff haben sollen.

Festlegen von EntitySets für die API Der Web-API muss mitgeteilt werden, welche EntitySets für die Nutzer verfügbar sein sollen. Dies hat mich zuerst verwirrt. Ich habe erwartet, dass die Web-API dies durch Lesen des AirlineContext erkennt. Als ich jedoch länger darüber nachgedacht habe, wurde mir klar, dass es sich ähnlich der Verwendung der SetEntitySetAccessRule-Methode in WCF Data Services verhält. In WCF Data Services definieren Sie, welche CRUD-Vorgänge zulässig sind, wenn gleichzeitig ein bestimmter Satz verfügbar gemacht wird. Mit der Web-API ändern Sie zunächst die WebApiConfig.Register-Methode, um festzulegen, welche Sätze zur API gehören sollen. Anschließend verwenden Sie die Methoden des Controllers, um die bestimmten CRUD-Vorgänge verfügbar zu machen. Sie legen die Sätze mithilfe der ODataModelBuilder-Klasse fest – ähnlich der DbContext.ModelBuilder-Klasse, die Sie möglicherweise mit Code First verwendet haben. Im Folgenden ist der Code in der Register-Methode der WebApiConfig-Datei angegeben, mit dem mein OData-Feed „Airlines“ und „Legs“ verfügbar macht:

ODataModelBuilder modelBuilder = new ODataConventionModelBuilder();
                  modelBuilder.EntitySet<Airline>("Airlines");
                  modelBuilder.EntitySet<FlightLeg>("Legs");

Definieren einer Route zum Suchen der OData Als Nächstes benötigt die Register-Methode eine Route, die auf dieses Modell verweist, sodass beim Aufruf für die Web-API Zugriff auf die definierten EntitySets gewährt wird:

Microsoft.Data.Edm.IEdmModel model = modelBuilder.GetEdmModel();
config.Routes.MapODataRoute("ODataRoute", "odata", model);

Sie werden feststellen, dass viele Demos „odata“ als RoutePrefix-Parameter verwenden, der das URL-Präfix für Ihre API-Methoden definiert. Obwohl dies ein praktischer Standardname ist, können Sie ihn beliebig benennen.

Daher ändere ich ihn, um meine Aussage zu unter Beweis zu stellen:

config.Routes.MapODataRoute("ODataRoute", "oairlinedata", model);

Umbenennen der Controllerklasse Die Anwendungsvorlage generiert Code, der eine einzigartige Benennungskonvention für Controller verwendet, wie zum Beispiel „AirlineController“ und „LegController“. Der Schwerpunkt von OData liegt jedoch auf den EntitySets, die normalerweise mit dem Plural des Entitätsnamens benannt werden. Und da meine EntitySets tatsächlich in der Pluralform vorliegen, muss ich den Namen meiner Controllerklasse zur Abstimmung mit dem EntitySet der Fluggesellschaft in „AirlinesController“ ändern.

Nutzung von OData

Nun kann ich mit der API arbeiten und dabei die vertraute OData-Abfragesyntax verwenden. Ich fordere zunächst eine Liste an, welche Daten verfügbar sind. Hierzu verwende ich folgende Anforderung: http://localhost:1702/oairlinedata/. Die Ergebnisse sind in Abbildung 5 dargestellt.

Abbildung 5: Anfordern einer Liste verfügbarer Daten

http://localhost:1702/oairlinedata/
<service xmlns="http://www.w3.org/2007/app" xmlns:atom=
  "http://www.w3.org/2005/Atom" 
  xml:base="http://localhost:1702/oairlinedata /">
    <workspace>
      <atom:title type="text">Default</atom:title>
      <collection href="Airlines">
        <atom:title type="text">Airlines</atom:title>
      </collection>
      <collection href="Legs">
        <atom:title type="text">Legs</atom:title>
      </collection>
    </workspace>
</service>

Die Ergebnisse verdeutlichen mir, dass der Dienst „Airlines“ und „Legs“ verfügbar macht. Als Nächstes fordere ich mit „http://localhost:1702/oairlinedata/Airlines“ eine Liste der Fluggesellschaften als OData an. OData kann als XML oder JSON zurückgegeben werden. Die Web-API-Ergebnisse werden standardmäßig im JSON-Format ausgegeben:

{
  "odata.metadata":
    "http://localhost:1702/oairlinedata/$metadata#Airlines","value":[
    {
      "Id":1,"Name":"Vermont Balloons","ModifiedDate":"2013-02-26T00:00:00"
    },{
      "Id":2,"Name":"Olympic Airways","ModifiedDate":"2013-02-26T00:00:00"
    },{
      "Id":3,"Name":"Salt Lake Flyer","ModifiedDate":"2013-02-26T00:00:00"
    }
  ]
}

Eine der vielen OData-URI-Features ist das Abfrageverfahren. Standardmäßig ermöglicht die Web-API keine Abfragevorgänge, da dies eine zusätzliche Last für den Server bedeutet. Das heißt, Sie können diese Abfragefeatures mit Ihrer Web-API so lange nicht verwenden, bis Sie den entsprechenden Methoden die Queryable-Anmerkung hinzufügen. Hier habe ich zum Beispiel „Queryable“ zur Get-Methode hinzugefügt:

[Queryable]
public override IQueryable<Airline> Get()
{
  return db.Airlines;
}

Nun können Sie die Methoden „$filter“, „$inlinecount“, „$orderby“, „$sort“ und „$top“ verwenden. Hier ist eine Abfrage, die die OData-Filtermethode verwendet:

http://localhost:1702/oairlinedata/Airlines?$filter=startswith(Name,'Vermont')

Mit dem ODataController können Sie die Abfragen einschränken, sodass die Nutzer keine Leistungsprobleme an Ihrem Server verursachen. Sie können beispielsweise die Anzahl der in einer Antwort zurückgegebenen Datensätze einschränken. Weitere Informationen hierzu finden Sie im Web-API-spezifischen Artikel zum OData-Sicherheitsleitfaden unter bit.ly/X0hyv3.

Allgemeiner Überblick über den Gesamtprozess

Ich habe nur einen Teil der Abfragefunktionen behandelt, die Sie mit dem Web API-OData-Support bereitstellen können. Sie können auch die virtuellen Methoden des EntitySetController verwenden, um eine Aktualisierung auf die Datenbank zu ermöglichen. Eine interessante Ergänzung zu PUT, POST und DELETE ist PATCH. Mit dieser Methode können Sie eine ausdrückliche und effiziente Anforderung für eine Aktualisierung senden, wenn nur wenige Felder geändert wurden, anstatt die vollständige Entität für eine POST-Methode zu senden. Die Logik in Ihrer PATCH-Methode muss jedoch eine richtige Aktualisierung verarbeiten können. Dies bedeutet sehr wahrscheinlich, dass bei der Verwendung von Entity Framework das aktuelle Objekt aus der Datenbank abgerufen und mit den neuen Werten aktualisiert wird. Wie Sie diese Logik implementieren, hängt davon ab, zu wissen, zu welchem Zeitpunkt im Workflow Sie den Preis für Übertragung der Daten über das Netzwerk bezahlen möchten. Ebenso ist es wichtig zu wissen, dass diese Version (mit dem ASP.NET- und Web Tools 2012.2-Paket) nur eine Untermenge der OData-Features unterstützt. Dies bedeutet, dass nicht alle der API-Aufrufe, die Sie für einen OData-Feed ausführen können, mit einem mit der Web-API erstellten OData-Anbieter funktionieren. In den Versionshinweisen für das ASP.NET- und Web Tools 2012.2-Paket ist angegeben, welche Features unterstützt werden.

Es gibt weitaus mehr zu lernen, aber das würde den Rahmen dieses Artikels sprengen. Ich empfehle Ihnen die ausgezeichnete Reihe von Mike Wasson zu OData in der offiziellen Web-API-Dokumentation unter bit.ly/14cfHIm. Hier erfahren Sie, wie Sie sämtliche CRUD-Methoden mithilfe der PATCH-Methode erstellen können. Sie lernen auch, wie Sie sogar mithilfe von Anmerkungen die in Ihren OData-APIs zulässigen Filtertypen einschränken können und wie Sie mit Beziehungen arbeiten. Bedenken Sie, dass viele der anderen Web-API-Features für die OData-API gelten, wie zum Beispiel die Verwendung der Autorisierung. Hiermit wird eingeschränkt, welche Person auf welche Vorgänge Zugriff hat. Der Blog zu .NET-Webentwicklung und Tools (blogs.msdn.com/webdev) enthält ebenfalls zahlreiche ausführliche Blogbeiträge zur OData-Unterstützung in der Web-API.

Julie Lerman ist Microsoft MVP, .NET-Mentor und Unternehmensberaterin und lebt in den Bergen von Vermont. Sie hält bei User Groups und Konferenzen in der ganzen Welt Vorträge zum Thema Datenzugriff und anderen Microsoft .NET-Themen. Julie Lerman führt einen Blog unter thedatafarm.com/blog. Sie ist die Autorin der Buchreihe „Programming Entity Framework“ (Programmieren des Entity Framework) (O’Reilly Media) und zahlreicher Onlinekurse auf Pluralsight.com. Folgen Sie ihr auf Twitter unter twitter.com/julielerman.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Jon Galloway (Microsoft) und Mike Wasson (Microsoft)
Jon Galloway (Jon.Galloway@microsoft.com) ist Technical Evangelist im Windows Azure-Evangelism-Team und beschäftigt sich vornehmlich mit ASP.NET MVC und ASP.NET Web API. Er hält Vorträge auf Konferenzen und internationalen Web Camps von Istanbul über Bangalore bis Buenos Aires. Er ist Mitautor der Buchreihe „Wrox Professional ASP.NET MVC“ und Mitherausgeber des Herding Code Podcast.
Mike Wasson (mwasson@microsoft.com) ist Programmierer und Autor bei Microsoft. Jahrelang hat er die Win32-Multimedia-APIs dokumentiert. Zurzeit schreibt er über ASP.NET, mit dem Schwerpunkt auf Web API.