Auswählen des richtigen API-Satzes in SharePoint

  • Artikel

Erfahren Sie mehr über die verschiedenen API-Gruppen, die in SharePoint bereitgestellt werden, einschließlich des Serverobjektmodells und der verschiedenen Clientobjektmodellen und des REST/OData-Webdiensts.

Faktoren, die bestimmen, welche API-Gruppe verwendet werden soll

Sie können aus verschiedenen API-Gruppen wählen, um auf die SharePoint-Plattform zuzugreifen. Welche Sie verwenden sollten, hängt von folgenden Faktoren ab:

  • Der Anwendungstyp. Die Möglichkeiten umfassen, sind jedoch nicht beschränkt auf die folgenden Kategorien, die sich nicht gegenseitig ausschließen: ein SharePoint-Add-In, ein Webpart auf einer SharePoint-Seite, eine Silverlight-Anwendung, die entweder auf einem Clientcomputer oder einem mobilen Clientgerät ausgeführt wird, eine ASP.NET Anwendung, die in SharePoint von einem IFrame verfügbar gemacht wird, JavaScript, das auf einer SharePoint-Websiteseite ausgeführt wird, Eine SharePoint-Anwendungsseite, eine Microsoft .NET Framework-Anwendung, die auf einem Clientcomputer ausgeführt wird, ein Windows PowerShell Skript und ein Zeitgeberauftrag, der auf einem SharePoint-Server ausgeführt wird.
  • Ihre vorhandenen Fachkenntnisse. Überraschenderweise können Sie Anwendungen in SharePoint erstellen, ohne sich mit dem Programmieren in SharePoint beschäftigen zu müssen. Sie können direkt mit der SharePoint-Entwicklung beginnen, wenn Sie bereits versiert im Umgang mit folgenden Programmierungsmodellen sind:
    • JavaScript
    • ASP.NET
    • REST/OData
    • .NET Framework
    • Windows Phone
    • Silverlight
    • Windows PowerShell
  • Das Gerät, auf dem der Code ausgeführt wird. Zu den Möglichkeiten gehört ein Server in der SharePoint-Farm, ein externer Server, wie z. B. ein Server in der Cloud, ein Client-Computer und ein Mobilgerät. In diesem Thema erhalten Sie einen Überblick zu den verschiedenen API-Gruppen, die von SharePoint bereitgestellt werden. In Abbildung 1 ist dargestellt, welche API-Gruppen verwendet werden können, um eine der 13 allgemeinen SharePoint-bezogenen Anwendungen zu entwickeln. Bei vielen Anwendungen können Sie verschiedene APIs auswählen.

Abbildung 1: Ausgewählte SharePoint-Erweiterungstypen und API-Gruppen in SharePoint

Mengendiagramm von API-Sätzen und SharePoint-App-Typen

In der folgenden Tabelle finden Sie Anleitungen dazu, welche API-Gruppen Sie für eine ausgewählte Liste allgemeiner SharePoint-Erweiterungsprojekte verwenden sollten. In den restlichen Abschnitten dieses Themas werden die verschiedenen API-Gruppen erläutert.

Wenn Sie diese Funktionen verwenden möchten... ... sollten Sie diese APIs einsetzen
Erstellen Sie eine ASP.NET-Webanwendung, die Erstell-/Lese-/Aktualisier-/Lösch-Vorgänge über eine Firewall zu SharePoint-Daten oder externen Daten durchführt, die in SharePoint durch einen Microsoft Business Connectivity Services (BCS) externen Inhaltstyp dargestellt werden JavaScript-Clientobjektmodell
Erstellen Sie eine ASP.NET-Webanwendung, die CRUD-Vorgänge zu SharePoint-Daten oder externen Daten durchführt, die in SharePoint durch einen externen BCS-Inhaltstyp dargestellt werden, SharePoint jedoch nicht über eine Firewall aufrufen müssen .NET Framework-Clientobjektmodell, Silverlight-Clientobjektmodell oder REST/OData-Endpunkte
Erstellen Sie eine LAMP-Webanwendung, die CRUD-Vorgänge zu SharePoint-Daten oder externen Daten durchführt, die in SharePoint durch einen externen BCS-Inhaltstyp dargestellt werden REST/OData-Endpunkte
Erstellen Sie eine Windows Phone-App, die CRUD-Vorgänge zu SharePoint-Daten durchführt Mobiles Clientobjektmodell
Erstellen Sie eine Windows Phone-App, die den Microsoft-Pushbenachrichtigungsdienst verwendet, um das Mobilgerät über Ereignisse in SharePoint zu benachrichtigen Mobiles Clientobjektmodell und das Serverobjektmodell
Erstellen Sie eine iOS- oder Android-App, die CRUD-Vorgänge zu SharePoint-Daten durchführt REST-/OData-Endpunkte
Erstellen Sie eine .NET Framework-Anwendung, die CRUD-Vorgänge zu SharePoint-Daten durchführt .NET Framework-Clientobjektmodell
Erstellen Sie eine Silverlight-Anwendung, die CRUD-Vorgänge zu SharePoint-Daten durchführt Silverlight-Clientobjektmodell
Erstellen Sie eine HTML/JavaScript-Anwendung, die CRUD-Vorgänge zu SharePoint-Daten durchführt JavaScript-Clientobjektmodell
Erstellen Sie eine Office-Add-In, die mit SharePoint funktioniert JavaScript-Clientobjektmodell
Erstellen Sie einen benutzerdefinierten Windows PowerShell-Befehl Serverobjektmodell
Erstellen eines Zeitgeberauftrags Serverobjektmodell
Erstellen einer Erweiterung der Zentraladministration Serverobjektmodell
Erstellen eines konsistenten Branding in einer ganzen SharePoint-Farm Serverobjektmodell
Erstellen eines benutzerdefinierten Webparts, einer Anwendungsseite oder eines ASP.NET-Benutzersteuerelements Serverobjektmodell
Wichtig: Wenn sich die Funktion, die Sie Kunden anbieten möchten, nicht an der SharePoint-Verwaltung in einem breiteren Bereich als eine Websitesammlung orientiert, wird empfohlen, anstatt das Serverobjektmodell zu verwenden, ein SharePoint-Add-In zu erstellen, das eine ASP.NET-Remote-Webanwendung mit benutzerdefinierten Webparts und ggf. Benutzersteuerelementen umfasst. Weitere Informationen dazu finden Sie in den oberen beiden Zeilen dieser Tabelle.

Serverobjektmodell

Die größte API-Gruppe befindet sich im Serverobjektmodell der verwalteten Klassen. Auf der SharePoint Foundation 2013-Ebene umfasst dieses Objektmodell Klassen und Elemente, mit denen die Programmsteuerung der Basiswebsite und der Listenstruktur von SharePoint Foundation erfolgen kann. Die meisten dieser Klassen befinden sich im Microsoft.SharePoint-Namespace . Darüber hinaus können Sie fast jede SharePoint Foundation-Komponente mithilfe des Serverobjektmodells erweitern, einschließlich Workflows, Warnungen, Webparts, einfacher Suche und Microsoft Business Connectivity Services (BCS). Das Serverobjektmodell umfasst außerdem umfangreiche API-Gruppen-Aktivierungserweiterungen der Verwaltung und des Sicherheitssystems von SharePoint Foundation, einschließlich Sicherung, Farmintegrität und Diagnose, Protokollierung, Farm- und Webanwendungsverwaltung, Upgrade, Bereitstellung, Zwischenspeicherung und Windows PowerShell-Anpassung.

Auf der SharePoint-Ebene werden noch viele weitere Klassen hinzugefügt, um die Programmierung von Enterprise Content Management (ECM), Benutzerprofilen, Taxonomien, der erweiterten Suche und weiterer Features von SharePoint zu ermöglichen.

Sie können LINQ to Objects verwenden, um eine beliebige IEnumerable-Sammlung im Arbeitsspeicher abzufragen, aber ein LINQ to SharePoint-Anbieter ermöglicht das direkte Abfragen der Listen in den SharePoint-Inhaltsdatenbanken. Genau genommen ist dieser Anbieter nicht für die anderen in diesem Thema erläuterten API-Gruppen verfügbar; es gibt jedoch Möglichkeiten, LINQ-Syntax für den Großteil der anderen Gruppen zu verwenden.

Die Assemblys, die die integrierten serverseitigen Klassen definieren, sind im globalen Assemblycache jedes Servers installiert, wenn SharePoint installiert ist. Wenn Sie etwas für das Serverobjektmodell programmieren, werden Ihre Assemblys als Farmlösungen im globalen Assemblycache installiert.

Hinweis

Das Entwickeln von neuen Sandkastenlösungen für SharePoint ist eine veraltete Methode, die dem Entwickeln von SharePoint-Add-Ins gewichen ist. Sandkastenlösungen können jedoch weiterhin in Websitesammlungen in SharePoint installiert werden. Die Assemblys dieser Lösungen verbleiben im Paket, sofern sie nicht verwendet werden, ansonsten werden sie temporär in einem Ordner auf dem Server installiert. Weitere Informationen finden Sie unter Wo werden Assemblys in Sandkastenlösungen bereitgestellt?.

Beschränkungen zum Verwenden des Serverobjektmodells

Benutzerdefinierte Logik in SharePoint-Add-Ins wird immer "nach unten" an den Client oder "nach oben" in die Cloud verteilt (oder "über" auf einen Server außerhalb der SharePoint-Farm). In all diesen Verteilungsmodellen muss eines der Clientobjektmodelle oder die die REST/OData-Endpunkte verwendet werden. (Sie können das Serverobjektmodell nicht in einem SharePoint-Add-In verwenden.) Wenn die App beispielsweise von SharePoint gehostete Seiten enthält, können diese Seiten mithilfe des JavaScript-Clientobjektmodells auf SharePoint-Daten zugreifen. Solche Seiten können auch Silverlight-Anwendungen verfügbar machen, die das SharePoint Silverlight-Clientobjektmodell verwenden. Weitere Informationen zu SharePoint-Add-Ins finden Sie unter Wichtige Aspekte der SharePoint-Add-In-Architektur und -Entwicklungslandschaft.

Clientobjektmodelle für verwalteten Code

SharePoint verfügt über drei Clientobjektmodelle für verwalteten Code: .NET, Silverlight und Mobil.

.NET-Clientobjektmodell

Das SharePoint-Objektmodell für .NET Framework wird in .NET Framework-Anwendungen verwendet, die auf einem Windows-Client (kein Telefon) ausgeführt werden. Folgende Clients gehören zu dieser Gruppe:

  • Ein Benutzer-Computer
  • Ein Server außerhalb der SharePoint-Farm
  • Eine Webrolle oder Workerrolle in Microsoft Azure

Nahezu jede Klasse im zentralen serverseitigen Objektmodell für Websites und Listen verfügt über eine entsprechende Klasse im .NET Framework-Clientobjektmodell. Außerdem macht das .NET Framework-Clientobjektmodell eine vollständige API-Gruppe zum Erweitern weiterer Features verfügbar. Dazu gehören einige SharePoint-Features, wie z. B. ECM, Taxonomie, Benutzerprofile, erweiterte Suche, Analyse, BCS und andere.

Um die Leistung zu verbessern, werden Codezeilen, die im .NET Framework Clientobjektmodell geschrieben werden, in Batches an den SharePoint-Server gesendet, wo sie in serverseitigen Code konvertiert und ausgeführt werden. Die abgefragten Ergebnisse und der neue Zustand aller Variablen werden dann an den Client zurückgegeben. Sie als Entwickler bestimmen, ob ein Batch synchron oder asynchron ausgeführt wird. (In einem synchronen Batch wartet die .NET Framework Anwendung auf die vom Server zurückgegebenen Ergebnisse, bevor sie fortfährt. In einem asynchronen Batch wird die clientseitige Verarbeitung sofort fortgesetzt, und die Clientbenutzeroberfläche bleibt reaktionsfähig.)

Sie können LINQ-Abfragesyntax in Ihrem Clientcode verwenden, um beliebige IEnumerable-Objekte abzufragen, dazu gehören auch SharePoint-Objekte, in denen IEnumerable implementiert ist. Wenn Sie dies jedoch tun, verwenden Sie LINQ to Objects und nicht den LINQ to SharePoint-Anbieter, sodass die Dokumentation des letzteren für clientseitigen Code nicht relevant ist.

Die Assemblys für das Objektmodell des .NET Framework-Clients müssen auf dem Client installiert sein. Sie sind in einem Weiterverteilungspaket enthalten, das Sie für die SharePoint-Clientkomponenten abrufen können.

Beispiele für die Verwendung des .NET Framework-Objektmodells finden Sie unter Abschließen grundlegender Vorgänge mit SharePoint-Clientbibliothekscode.

Hinweis

Sie können auch die SharePoint REST/OData-Endpunkte in einer .NET Framework-Anwendung verwenden. Einen Vergleich des .NET Framework Clientobjektmodells mit den SharePoint REST/OData-Endpunkten finden Sie im Abschnitt REST/OData-Endpunkte weiter unten in diesem Artikel.

Silverlight-Clientobjektmodell

Das SharePoint-Objektmodell für Silverlight wird in Silverlight-Anwendungen unabhängig davon verwendet, wo die kompilierte XAP-Datei gespeichert ist. Das kann eine Objektbibliothek auf einer SharePoint-Website, ein Client-Computer, ein Cloud-Speicher oder ein externer Server sein. In der Regel wird eine Silverlight-Anwendung in SharePoint in einem SilverlightWebPart-Objekt angezeigt. Das Silverlight-Clientobjektmodell in SharePoint ist fast identisch mit dem .NET Framework-Clientobjektmodell und umfasst Unterstützung für die gleichen Erweiterbarkeitsbereiche. Der Hauptunterschied liegt darin, dass in der Silverlight-Version alle Batches der Befehle asynchron an den Server gesendet werden, damit die Benutzeroberfläche aktiv bleibt.

Die Assemblys für das Silverlight-Clientobjektmodell werden auf jedem SharePoint-Server unter %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS\ClientBin gespeichert. Sie müssen nicht auf dem Computer installiert werden, auf dem die Silverlight-Anwendung läuft, haben jedoch die Möglichkeit dazu. Sie können sie auch in der XAP-Datei der Anwendung zu einem Paket zusammenfassen.

Silverlight-XAP-Dateien können in SharePoint-Add-Ins eingeschlossen werden, einschließlich von SharePoint gehosteter Apps. Im letzteren Fall wird die XAP-Datei in einer Bibliothek im App-Web bereitgestellt. (Weitere Informationen zu App-Webs finden Sie unter Hostwebs, Add-In-Webs und SharePoint-Komponenten in SharePoint.) Dies macht eine Silverlight-Anwendung zu einer nützlichen Möglichkeit, benutzerdefinierten SharePoint-Code in eine App einzufügen, da benutzerdefinierter serverseitiger Code in SharePoint-Add-Ins nicht zulässig ist. Außerdem können Silverlight-Entwickler ihre vorhandenen Fähigkeiten nutzen, um SharePoint-Anwendungen mit minimaler Lernkurve zu erstellen.

Hinweis

Sie können auch die SharePoint REST-/OData-Endpunkte in einer Silverlight-Anwendung verwenden. Einen Vergleich des Silverlight-Clientobjektmodells mit den SharePoint REST/OData-Endpunkten finden Sie im Abschnitt REST/OData-Endpunkte weiter unten in diesem Artikel.

Mobiles Objektmodell

Eine spezielle Version des Silverlight-Clientobjektmodells ist für Windows Phone-Geräte verfügbar. Es umfasst zusätzliche APIs, die nur für Telefone relevant sind, wie z. B. APIs, mit der sich eine Smartphone-App für Benachrichtigungen vom Microsoft-Pushbenachrichtigungsdienst registrieren kann. Es unterstützt alle kernigen SharePoint-Funktionen. Es bietet jedoch keine Unterstützung für die Nicht-Kern-Erweiterbarkeitsbereiche, die von den anderen beiden Clientobjektmodellen für verwalteten Code unterstützt werden. Verwenden Sie zum Zugreifen auf diese zusätzlichen Bereiche die SharePoint REST/OData-Endpunkte in Ihrer mobilen App. Weitere Informationen dazu finden Sie im Abschnitt REST/OData-Endpunkte weiter unten in diesem Artikel.

Die Assemblys für das mobile Objektmodell werden auf jedem SharePoint-Server unter %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS\ClientBin gespeichert. Sie können Sie in der XAP-Datei in Ihrer Windows Phone-Anwendung zu einem Paket zusammenfassen.

JavaScript-Objektmodell

SharePoint bietet ein JavaScript-Objektmodell zur Verwendung in Inlineskripts oder in gesonderten JS-Dateien. Es umfasst die gleiche Funktionalität wie die Clientobjektmodelle von .NET Framework und Silverlight. Wie das Silverlight-Clientobjektmodell ist das JavaScript-Objektmodell eine nützliche Möglichkeit, benutzerdefinierten SharePoint-Code in eine App einzufügen, da benutzerdefinierter serverseitiger Code in SharePoint-Add-Ins nicht zulässig ist. Außerdem können Webentwickler ihre vorhandenen JavaScript-Kenntnisse nutzen, um SharePoint-Anwendungen mit minimaler Lernkurve zu erstellen.

Genau wie Objektmodelle mit verwaltetem Code interagiert die JavaScript-Infrastruktur für SharePoint mit den Farm-Servern in Batches. Diese Batches werden immer asynchron ausgeführt. Außerdem ist es nun möglich, in JavaScript domänenübergreifend auf SharePoint-Daten zuzugreifen (jedoch nur Daten, die sich in der gleichen übergeordneten Websitesammlung befinden), was in vorherigen SharePoint-Versionen nicht möglich war. Weitere Informationen finden Sie unter Zugreifen auf SharePoint-Daten über Add-Ins mithilfe der domänenübergreifenden Bibliothek. Daten werden in JavaScript Object Notation (JSON) vom Server zurückgegeben.

Das JavaScript-Objektmodell wird in einer Gruppe von *.js Dateien definiert, die sich unter %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS auf jedem Server befinden.

Beispiele für die Verwendung des .NET Framework-Objektmodells finden Sie unter Abschließen grundlegender Vorgänge mit JavaScript-Bibliothekscode in SharePoint.

Hinweis

Sie können auch die SharePoint REST-/OData-Endpunkte in einer JavaScript-Anwendung verwenden. Einen Vergleich des JavaScript-Clientobjektmodells mit den REST/OData-Endpunkten von SharePoint finden Sie im folgenden Abschnitt REST/OData-Endpunkte.

REST/OData-Endpunkte

Für Szenarien, in denen Sie von Clienttechnologien aus auf SharePoint-Entitäten zugreifen müssen, die kein JavaScript verwenden und nicht auf den .NET Framework- oder Silverlight-Plattformen basieren, stellt SharePoint eine Implementierung eines REST-Webdiensts (Representational State Transfer) bereit, der das OData-Protokoll verwendet, um CRUD-Vorgänge für SharePoint-Listendaten auszuführen. Darüber hinaus verfügt fast jede API in den Clientobjektmodellen über einen entsprechenden REST-Endpunkt. Dadurch kann Ihr Code direkt mit SharePoint-Artefakten interagieren, indem jede Technologie verwendet wird, die standard-HTTP-Anforderungen und -Antworten unterstützt. Um die in SharePoint integrierten REST-Funktionen zu verwenden, erstellt Ihr Code eine RESTful-HTTP-Anforderung an einen Endpunkt, der der gewünschten Clientobjektmodell-API entspricht. Der Client.svc-Webdienst verarbeitet die HTTP-Anforderung und liefert eine Antwort im Atom- oder JSON-Format.

Weitere Informationen zur Verwendung des REST/OData-Webdiensts finden Sie im Knoten Verwenden von OData-Abfragevorgängen in SharePoint-REST-Anforderungen. Beispiele finden Sie im Thema Abschließen grundlegender Vorgänge mit SharePoint-REST-Endpunkten.

Vergleich zur REST/OData-Programmierung mit der Clientobjektmodell-Programmierung

In einigen Situationen kann es vorzuziehen sein, die REST-Endpunkte auch in Anwendungen zu verwenden, für die ein SharePoint-Objektmodell verfügbar ist, insbesondere für Entwickler, die nicht über Windows-Entwicklungserfahrung verfügen. Die folgende Tabelle enthält einen Vergleich der wichtigsten Features dieser Programmieroptionen für Entwickler, die eine Anwendung auf einer Windows-Plattform oder mit einer Plattform erstellen, die JavaScript unterstützt.

Funktion .NET Framework oder Silverlight-Objektmodelle JavaScript-Objektmodell Von einer Windows-Plattform oder von JavaScript abgerufene REST/OData-Endpunkte
Objektorientiertes Programmieren Ja Ja Nein
Batch-Verarbeitung Ja Ja Ja
APIs für die bedingte Verarbeitung und Ausnahmebehandlungen Ja Nein Nein
Verfügbarkeit der LINQ-Syntax Ja Nein Nein
Kombinieren von Listendaten aus verschiedenen SharePoint-Webanwendungen Ja Nein Ja
Vertrautheit für erfahrene REST/OData-Entwickler Nein Nein Ja
Ähnlichkeiten zur nicht-Windows-Programmierung oder JavaScript-Programmierung Nein Ja Ja
Starke Typisierung für Listenelementfelder Nein (außer mit LINQ) Nein Ja, von einer Windows-Plattform; Nein, von JavaScript
Nutzen von jQuery, Knockout und anderen JavaScript-Bibliotheken Nein Ja Nein, von einer Windows-Plattform; Ja, von JavaScript

Framework für die WCF Data Services

Wenn Sie die LINQ-Syntax lieber in .NET Framework- oder Silverlight-Clientanwendungen verwenden möchten, unterstützt SharePoint WCF Data Services als LINQ-Anbieter. Sie können wie in vorherigen Versionen von SharePoint Foundation die "listdata.svc" (nur für Listendaten) vorgeben, oder die gleiche "client.svc" vorgeben, die die OData-Schnittstelle für den Zugriff auf alle SharePoint-Entitäten und Listendaten unterstützt. Weitere Informationen dazu finden Sie unter Abfragen von SharePoint Foundation mit ADO.NET Data Services.

Abbildung 2 veranschaulicht die Beziehung zwischen den verschiedenen Client-APIs, den verschiedenen Arten von Client-Anwendungen und SharePoint. Die unterschiedlichen _api-URLs sind die farmrelativen URLs für die REST-Endpunkte. Weitere Informationen dazu finden Sie unter dem Thema Weitere Informationen zum SharePoint 15 REST-Dienste.

Abbildung 2: Client-Anwendungen und APIs in SharePoint

Programmiermodell für Apps für SharePoint

Veraltete API-Gruppen

Aus Gründen der Abwärtskompatibilität werden weiterhin zwei API-Sätze im SharePoint-Framework unterstützt. Es wird jedoch empfohlen, sie nicht für neue Projekte zu verwenden: die ASP.NET -Webdienste (asmx) und direkte RPC-Aufrufe (Remote Procedure Calls) an die owssvr.dll-Datei .

Siehe auch