Ausführen grundlegender Vorgänge unter Verwendung von SharePoint-REST-Endpunkten

You can perform basic create, read, update, and delete (CRUD) operations by using the Representational State Transfer (REST) interface provided by SharePoint. The REST interface exposes all the SharePoint entities and operations that are available in the other SharePoint client APIs. One advantage of using REST is that you don't have to add references to any SharePoint libraries or client assemblies. Instead, you make HTTP requests to the appropriate endpoints to retrieve or update SharePoint entities, such as webs, lists, and list items.

Eine Einführung in die SharePoint-REST-Schnittstelle und ihre Architektur finden Sie unter Grundlegendes zum SharePoint REST-Dienst.

Informationen zum Arbeiten mit den wichtigsten SharePoint-Entitäten finden Sie unter Arbeiten mit Listen und Listenelementen unter Verwendung von REST und Arbeiten mit Ordnern und Dateien unter Verwendung von REST.

Ein Beispiel, in dem gezeigt wird, wie viele dieser Vorgänge im Kontext einer in C# geschriebenen ASP.NET-Webanwendung ausgeführt werden, finden Sie unter SharePoint-Add-in-REST-OData-BasicDataOperations.

Informationen zu den Gruppen von APIs, die auf der SharePoint-Plattform verfügbar sind, finden Sie unter Auswählen des richtigen API-Satzes in SharePoint.

Informationen zum Verwenden der anderen Client-APOs finden Sie in folgenden Themen:

HTTP-Operationen in SharePoint-REST-Diensten

The endpoints in the SharePoint REST service correspond to the types and members in the SharePoint client object models. By using HTTP requests, you can use these REST endpoints to perform typical CRUD (Create, Read, Update, and Delete) operations against SharePoint entities, such as lists and sites.

In der Regel entsprechen Endpunkte, die Lese-Operationen darstellen, HTTP-GET-Befehlen. Endpunkte, die Erstellungsoperationen darstellen, entsprechen HTTP-POST-Befehlen, und Endpunkte, die Aktualisierungs- oder Einfügeoperationen darstellen, entsprechen HTTP-PUT-Befehlen.

In SharePoint verwenden Sie POST, um Entitäten wie Listen und Websites zu erstellen. Der SharePoint-REST-Dienst unterstützt das Senden von POST-Befehlen, die Objektdefinitionen enthalten, an Endpunkte, die Auflistungen darstellen. Sie können beispielsweise einen POST-Befehl, der eine neue Listenobjektdefinition in ATOM enthält, an die folgende URL senden, um eine SharePoint-Liste zu erstellen:

http://<site url>/_api/web/lists

Alle nicht erforderlichen Eigenschaften in POST-Operationen werden auf ihre Standardwerte festgelegt. Wenn Sie eine schreibgeschützte Eigenschaft im Rahmen einer POST-Operation festzulegen versuchen, gibt der Dienst eine Ausnahme zurück.

Verwenden Sie die Operationen PUT und MERGE, um vorhandene SharePoint-Objekte zu aktualisieren. Jeder Dienstendpunkt, der eine set-Operation für eine Objekteigenschaft darstellt, unterstützt PUT-Anforderungen und MERGE-Anforderungen. Bei MERGE-Anforderungen ist das Festlegen von Eigenschaften optional. Alle Eigenschaften, die Sie nicht explizit festlegen, behalten ihre aktuelle Eigenschaft. Bei PUT-Befehlen werden jedoch alle Eigenschaften, die Sie nicht explizit festlegen, auf ihre Standardeigenschaften festgelegt. Darüber hinaus gibt der REST-Dienst eine Ausnahme zurück, wenn Sie bei Verwendung von HTTP- PUT-Befehlen nicht alle erforderlichen Eigenschaften in Objektaktualisierungen angeben.

Verwenden Sie den HTTP- DELETE-Befehl für die spezifische Endpunkt-URL, um das durch den Endpunkt dargestellte SharePoint-Objekt zu löschen. Bei wiederverwendbaren Objekten, wie Listen, Dateien und Listenelementen, führt dies zu einer Recycle-Operation.

Lesen von Daten mit der SharePoint-REST-Schnittstelle

Um die in SharePoint integrierten REST-Funktionen zu nutzen, erstellen Sie eine RESTful-HTTP-Anforderung mit dem OData-Standard, die der Clientobjektmodell-API entspricht, die Sie verwenden möchten. Jede SharePoint-Entität wird an einem Endpunkt auf der SharePoint-Website verfügbar gemacht, die Sie verwenden möchten, und ihre Metadaten werden entweder im XML- oder JSON-Format dargestellt. Sie können die HTTP-Anforderungen in jeder beliebigen Sprache durchführen, auch in JavaScript und C#.

To read information from a REST endpoint, you must know both the URL of the endpoint and the OData representation of the SharePoint entity that is exposed at that endpoint. For example, to retrieve all the lists in a specific SharePoint site, you would make a GET request to http://<site url>/_api/web/lists. You can navigate to this URL in your browser and see the XML that gets returned. When you make the request in code, you can specify whether to receive the OData representation of the lists in XML or JSON.

The following C# code demonstrates how to make this GET request that returns a JSON representation of all of a site's lists by using JQuery. It also assumes that you have a valid OAuth access token that is stored in the accessToken variable. You do not need the access token if you make this call from inside an add-in web, as you would in a SharePoint-hosted add-in. Note that you cannot obtain an access token from code that is running on a browser client. You must obtain the access token from code that is running on a server.

Weitere Informationen über das Abrufen eines Zugriffstokens finden Sie unter OAuth-Ablauf mit Kontexttoken für Add-Ins in SharePoint und OAuth-Ablauf mit Authentifizierungscode für SharePoint-Add-Ins

HttpWebRequest endpointRequest =
  (HttpWebRequest)HttpWebRequest.Create(
  "http://<site url>/_api/web/lists");
endpointRequest.Method = "GET";
endpointRequest.Accept = "application/json;odata=verbose";
endpointRequest.Headers.Add("Authorization",
  "Bearer " + accessToken);
HttpWebResponse endpointResponse =
  (HttpWebResponse)endpointRequest.GetResponse();

This request would look a little different if you are writing your add-in in JavaScript while using the SharePoint cross-domain library. In this case, you don't need to provide an access token.

The following code demonstrates how this request would look if you are using the cross-domain library and want to receive the OData representation of the lists as XML instead of JSON. (Because Atom is the default response format, you don't have to include an Accept header.) For more information about using the cross-domain library, see Access SharePoint data from add-ins using the cross-domain library.

var executor = new SP.RequestExecutor(appweburl);
executor.executeAsync(
  {
    url: appweburl +
          "/_api/SP.AppContextSite(@target)/web/lists?@target='" +
          hostweburl + "'",
    method: "GET",
    success: successHandler,
    error: errorHandler
  }
);

Der Code im folgenden Beispiel zeigt, wie Sie eine JSON-Darstellung aller Listen in einer Website anfordern, indem Sie C# verwenden. Das Beispiel geht davon aus, dass Sie über einen OAuth-Zugriffstoken verfügen, den Sie in der accessToken-Variablen speichern.

HttpWebRequest endpointRequest = (HttpWebRequest)HttpWebRequest.Create(sharepointUrl.ToString() + "/_api/web/lists");
endpointRequest.Method = "GET";
endpointRequest.Accept = "application/json;odata=verbose";
endpointRequest.Headers.Add("Authorization", "Bearer " + accessToken);
HttpWebResponse endpointResponse = (HttpWebResponse)endpointRequest.GetResponse();

Abrufen von Eigenschaften, die nicht mit der Ressource zurückgegeben werden

Viele Eigenschaftswerte werden zurückgegeben, wenn Sie eine Ressource abrufen. Bei einigen Eigenschaften müssen Sie allerdings eine GET-Anforderung direkt an den Eigenschaftsendpunkt senden. Dies gilt i. d. R. für Eigenschaften, die SharePoint-Entitäten darstellen.

Das folgende Beispiel zeigt, wie Sie eine Eigenschaft abrufen, indem Sie den Namen der Eigenschaft an den Ressourcenendpunkt anhängen. Im Beispiel wird der Wert der Eigenschaft Author von einer File-Ressource abgerufen.

http://<site url>/_api/web/getfilebyserverrelativeurl('/<folder name>/<file name>')/author

Um die Ergebnisse im JSON-Format zu erhalten, fügen Sie einen Accept-Header zu "application/json;odata=verbose" hinzu.

Schreiben von Daten unter Verwendung der REST-Schnittstelle

Sie können SharePoint-Entitäten erstellen und aktualisieren, indem Sie RESTful-HTTP-Anforderungen an die entsprechenden Endpunkte erstellen, genauso wie beim Lesen von Daten. Ein wesentlicher Unterschied dabei ist jedoch, dass Sie eine POST-Anforderung verwenden. Beim Aktualisieren von Entitäten übergeben Sie außerdem eine PUT- oder MERGE-HTTP-Anforderungsmethode, indem Sie einen dieser Begriffe den Headern Ihrer Anforderung als Wert des X-HTTP-Method-Schlüssels hinzufügen. Die MERGE-Methode aktualisiert nur die Eigenschaften der von Ihnen angegebenen Entität, während die PUT-Methode die bestehende Entität durch eine neue ersetzt, die Sie im Textkörper der POST-Anforderung angeben. Verwenden Sie die DELETE-Methode, um die Entität zu löschen. Beim Erstellen oder Aktualisieren einer Entität müssen Sie eine OData-Darstellung der Entität, die Sie erstellen oder ändern möchten, im Textkörper Ihrer HTTP-Anforderung bereitstellen.

Eine weitere wichtige Überlegung beim Erstellen, Aktualisieren und Löschen von SharePoint-Entitäten ist, dass diese Vorgänge auch den Anforderungsformular-Digestwert des Servers als Wert des X-RequestDigest-Headers erfordern, wenn Sie nicht OAuth verwenden, um Ihre Anforderungen zu autorisieren. Sie können diesen Wert abrufen, indem Sie eine POST-Anforderung mit leerem Textkörper an http://<site url>/_api/contextinfo senden und den Wert des d:FormDigestValue-Knotens aus der XML-Datei extrahieren, das der contextinfo-Endpunkt zurückgibt. Das folgende Beispiel zeigt eine HTTP-Anforderung an den contextinfo-Endpunkt in C#.

HttpWebRequest endpointRequest =(HttpWebRequest)HttpWebRequest.Create(
                                    "http://<site url>/_api/contextinfo");
endpointRequest.Method = "POST";
endpointRequest.Accept = "application/json;odata=verbose";
HttpWebResponse endpointResponse = (HttpWebResponse)endpointRequest.GetResponse();

Wenn Sie den unter Autorisierung und Authentifizierung für SharePoint-Add-Ins beschriebenen Authentifizierungs- und Autorisierungsablauf verwenden, müssen Sie den Anforderungsdigest nicht in Ihre Anforderungen einschließen.

Wenn Sie die domänenübergreifende JavaScript-Bibliothek verwenden, übernimmt SP.RequestExecutor das Abrufen und Senden des Formulardigestwerts für Sie.

If you're creating a SharePoint-hosted SharePoint Add-in, you don't have to make a separate HTTP request to retrieve the form digest value. Instead, you can retrieve the value in JavaScript code from the SharePoint page (if the page uses the default master page), as shown in the following example, which uses JQuery and creates a list.

jQuery.ajax({
        url: "http://<site url>/_api/web/lists",
        type: "POST",
        data:  JSON.stringify({ '__metadata': { 'type': 'SP.List' }, 'AllowContentTypes': true,
 'BaseTemplate': 100, 'ContentTypesEnabled': true, 'Description': 'My list description', 'Title': 'Test' }
),
        headers: {
            "accept": "application/json;odata=verbose",
            "content-type": "application/json;odata=verbose",
            "content-length": <length of post body>,
            "X-RequestDigest": $("#__REQUESTDIGEST").val()
        },
        success: doSuccess,
        error: doError
});

Das folgende Beispiel zeigt, wie Sie die im vorherigen Beispiel erstellte Liste aktualisieren. In dem Beispiel wird der Titel der Liste geändert, JQuery wird verwendet, und es wird davon ausgegangen, dass Sie diese Operation in einem in SharePoint gehosteten Add-In durchführen.

jQuery.ajax({
        url: "http://<site url>/_api/web/lists/GetByTitle('Test')",
        type: "POST",
        data: JSON.stringify({ '__metadata': { 'type': 'SP.List' }, 'Title': 'New title' }),
        headers: {
            "X-HTTP-Method":"MERGE",
            "accept": "application/json;odata=verbose",
            "content-type": "application/json;odata=verbose",
            "content-length": <length of post body>,
            "X-RequestDigest": $("#__REQUESTDIGEST").val(),
            "IF-MATCH": "*"
        },
        success: doSuccess,
        error: doError
});

The value of the IF-MATCH key in the request headers is where you specify the etag value of a list or list item. This particular value applies only to lists and list items, and is intended to help you avoid concurrency problems when you update those entities. The previous example uses an asterisk (*) for this value, and you can use that value whenever you don't have any reason to worry about concurrency issues. Otherwise, you should obtain the etag value or a list or list item by performing a GET request that retrieves the entity. The response headers of the resulting HTTP response pass the etag as the value of the ETag key. This value is also included in the entity metadata.

The following example shows the opening <entry> tag for the XML node that contains the list information. The m:etag property contains the etag value.

<entry xml:base="http://site url/_api/" xmlns=http://www.w3.org/2005/Atom
       xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"
       xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
       xmlns:georss="http://www.georss.org/georss" xmlns:gml="http://www.opengis.net/gml" m:etag=""1"">

Erstellen einer Website mit REST

Das folgende Beispiel zeigt, wie Sie eine Website in JavaScript erstellen können.

jQuery.ajax({
    url: "http://<site url>/_api/web/webinfos/add",
    type: "POST",
    data: JSON.stringify(
        {'parameters': {
            '__metadata':  {'type': 'SP.WebInfoCreationInformation' },
            'Url': 'RestSubWeb',
            'Title': 'RestSubWeb',
            'Description': 'REST created web',
            'Language':1033,
            'WebTemplate':'sts',
            'UseUniquePermissions':false}
        }
    ),
    headers: {
        "accept": "application/json; odata=verbose",
        "content-type":"application/json;odata=verbose",
        "content-length": <length of post body>,
        "X-RequestDigest": $("#__REQUESTDIGEST").val()
    },
    success: doSuccess,
    error: doError
});

Hinweis

Setting WebTemplate to 'sts' will create a modern homepage. To create a classic homepage, set WebTemplate to 'sts#0'.

So unterscheiden sich REST-Anforderungen je nach Umgebung

Der Vorgang zum Erstellen und Senden einer HTTP-Anforderung kann je nach Sprache, Bibliothek und Add-In-Typ variieren, sodass Sie häufig mindestens eine Anforderungskomponente ändern müssen, wenn Sie eine Anforderung aus einer Umgebung in eine andere übertragen. jQuery AJAX-Anforderungen verwenden beispielsweise data- und type-Parameter, um den Anforderungstext und -typ anzugeben, während domänenübergreifende Bibliotheksanforderungen body- und method-Parameter zum Angeben dieser Werte verwenden.

In den folgenden Abschnitten werden weitere allgemeine Unterschiede zwischen Umgebungen beschrieben.

Wie Sie den Formulardigestwert abrufen und senden, hängt von dem Add-In ab

Wenn Sie eine POST-Anforderung senden, muss die Anforderung im X-RequestDigest-Header den Formulardigestwert enthalten. Wie Sie den Wert abrufen und senden, ist jedoch je nach Add-In unterschiedlich:

  • In von SharePoint gehosteten Add-Ins können Sie einfach den folgenden Header übergeben:

    "X-RequestDigest": $("#__REQUESTDIGEST").val()

  • Rufen Sie in Cloud-gehosteten Add-Ins, die OAuth verwenden, zuerst den Formulardigestwert ab, indem sie eine Anforderung an den contextinfo-Endpunkt senden, und dann der Anforderung den Wert hinzufügen, wie unter Schreiben von Daten unter Verwendung der REST-Schnittstelle gezeigt.

  • In Cloud-gehosteten Add-Ins, welche die domänenübergreifende JavaScript-Bibliothek verwenden, müssen Sie den Formulardigestwert nicht angeben. SP.RequestExecutor gibt diesen automatisch für Sie an (ebenso wie den Inhalt-Länge-Wert).

Add-Ins, die OAuth verwenden, müssen Zugriffstoken in Anforderungen übergeben

Cloud-hosted add-ins use either OAuth or the cross-domain library to authorize access to SharePoint data. Add-in components with code that runs on a remote web server must use OAuth to authorize access to SharePoint data. In this case, you need to include an Authorization header to send the access token. For an example that adds an authorization header to an HTTPWebRequest object, see Reading data with the SharePoint REST interface.

Hinweis

Cloud-hosted add-in components that are written in JavaScript must use the SP.RequestExecutor object in the cross-domain library to access to SharePoint data. Cross-domain library requests don't need to include an access token.

Weitere Informationen zu OAuth-Zugriffstoken und wie diese abgerufen werden, finden Sie unter OAuth-Ablauf mit Kontexttoken für Add-Ins in SharePoint und OAuth-Ablauf mit Authentifizierungscode für SharePoint-Add-Ins.

Endpunkt-URIs in domänenübergreifenden Bibliotheksanforderungen verwenden "SP.AppContextSite", um den Kontext zu ändern

Die Anforderungen werden an den in der url-Eigenschaft der Anforderung angegebenen Ressourcenendpunkt gesendet. Endpunkt-URIs verwenden das folgende Format:

<site url>/_api/<context>/<resource> (zum Beispiel https://contoso.com/_api/web/lists)

Domänenübergreifende Bibliotheksanforderungen verwenden dieses Format für den Zugriff auf Daten im Add-In-Web. Dies ist der Standardkontext für domänenübergreifende Bibliotheksanforderungen. Um jedoch auf Daten im Hostweb oder in einer anderen Websitesammlung zugreifen zu können, müssen die Anforderungen das Hostweb oder die andere Websitesammlung als Kontext initialisieren. Hierzu wird wie in Tabelle 1 gezeigt der SP.AppContextSite-Endpunkt im URI verwendet. Die in Tabelle 1 aufgeführten Beispiel-URIs verwenden den @target-Alias zum Senden der Ziel-URL in der Abfragezeichenfolge, weil die URL ein Sonderzeichen (':') enthält.

Hinweis

Damit ein in der Cloud gehostetes Add-In beim Verwenden der domänenübergreifenden Bibliothek auf SharePoint-Daten zugreifen kann, ist eine Add-In-Webinstanz erforderlich.

Tabelle 1: Verwenden des „SP.AppContextSite“-Endpunkts zum Ändern des Kontexts der Anforderung

Add-In-Typ Szenario für den domänenübergreifenden Datenzugriff Beispiel-Endpunkt-URI
In der Cloud gehostet JavaScript-Add-In-Komponente, die mithilfe der domänenübergreifenden Bibliothek auf Hostwebdaten zugreift <app web url>/_api/SP.AppContextSite(@target)/web/lists?@target='<host web url>'
In der Cloud gehostet JavaScript-Add-In-Komponente, die mithilfe der domänenübergreifenden Bibliothek auf Daten zugreift, die sich in einer anderen Websitesammlung als dem Hostweb befinden (gilt nur für Add-Ins mit Mandantenbereich) <app web url>/_api/SP.AppContextSite(@target)/web/title?@target='<target site url>'
Von SharePoint gehostet Add-In-Webkomponente, die auf Daten in einer anderen Websitesammlung zugreift (gilt nur für Add-Ins mit Mandantenbereich) <app web url>/_api/SP.AppContextSite(@target)/web/title?@target='<target site url>'

Hinweis

In Szenarien für den domänenübergreifenden Datenzugriff sind auch die entsprechenden Add-In-Berechtigungen erforderlich. Weitere Informationen finden Sie unter Zugreifen auf Daten in einem Hostweb und Zugreifen auf Daten in allen Websitesammlungen.

SharePoint Add-ins can get the add-in web URL and host web URL from the query string of the add-in page, as shown in the following code example. The example also shows how to reference the cross-domain library, which is defined in the SP.RequestExecutor.js file on the host web. The example assumes that your add-in launches from SharePoint. For guidance about setting your SharePoint context correctly when your add-in does not launch from SharePoint, see Authorization Code OAuth flow for SharePoint Add-ins.

var hostweburl;
var appweburl;

// Get the URLs for the add-in web the host web URL from the query string.
$(document).ready(function () {
  //Get the URI decoded URLs.
  hostweburl = decodeURIComponent(getQueryStringParameter("SPHostUrl"));
  appweburl = decodeURIComponent(getQueryStringParameter("SPAppWebUrl"));

  // Load the SP.RequestExecutor.js file.
  $.getScript(hostweburl + "/_layouts/15/SP.RequestExecutor.js", runCrossDomainRequest);
});

// Build and send the HTTP request.
function runCrossDomainRequest() {
  var executor = new SP.RequestExecutor(appweburl);
  executor.executeAsync({
      url: appweburl + "/_api/SP.AppContextSite(@target)/web/lists?@target='" + hostweburl + "'",
      method: "GET",
      headers: { "Accept": "application/json; odata=verbose" },
      success: successHandler,
      error: errorHandler
  });
}

// Get a query string value.
// For production add-ins, you may want to use a library to handle the query string.
function getQueryStringParameter(paramToRetrieve) {
  var params = document.URL.split("?")[1].split("&amp;");
  var strParams = "";
  for (var i = 0; i < params.length; i = i + 1) {
    var singleParam = params[i].split("=");
    if (singleParam[0] == paramToRetrieve) return singleParam[1];
  }
}
??? // success and error callback functions

In REST-Anforderungen verwendete Eigenschaften

In Tabelle 2 werden häufig in HTTP-Anforderungen für den SharePoint-REST-Dienst verwendete Eigenschaften aufgeführt.

Tabelle 2: Verwendung von REST-Anforderungseigenschaften in HTTP-Anforderungen

Eigenschaften Wann erforderlich Beschreibung
url Alle Anforderungen Die URL eines REST-Ressourcenendpunkts. Beispiel: http://<site url>/_api/web/lists
method (oder type) Alle Anforderungen Die HTTP-Anforderungsmethode: GET für Lesevorgänge und POST für Schreibvorgänge. POST-Anforderungen können Aktualisierungs- oder Löschvorgänge durchführen, wenn das Verb DELETE, MERGE oder PUT im X-HTTP-Method-Header angegeben wird.
body (oder data) POST-Anforderungen, die Daten im Anforderungstextkörper senden Der Textkörper der POST-Anforderung. Sendet Daten (z. B. komplexe Typen), die nicht in einer Endpunkt-URI gesendet werden können. Wird mit dem content-length-Header verwendet.
Authentication-Header Remote-Add-Ins, die OAuth verwenden, um Benutzer zu authentifizieren. Gilt nicht bei Verwendung von JavaScript oder der domänenübergreifenden Bibliothek. Sendet den OAuth-Zugriffstoken (erhalten von einem sicheren Token-Server von Microsoft Access Control Service (ACS)), der zur Authentifizierung der Anforderung des Nutzers verwendet wird. Beispiel: "Authorization": "Bearer " + accessToken, wobei accessToken für die Variable steht, die den Token enthält. Token müssen mittels serverseitigem Code abgerufen werden.
X-RequestDigest-Header POST-Anforderungen (außer SP.RequestExecutor-Anforderungen) Remote-Add-Ins, die OAuth verwenden, können den Formulardigestwert vom Endpunkt http://<site url>/_api/contextinfo abrufen. In SharePoint gehostete Add-Ins können den Wert über das #__REQUESTDIGEST-Seitensteuerelement abrufen, wenn es auf der SharePoint-Seite verfügbar ist. Weitere Informationen finden Sie unter Schreiben von Daten unter Verwendung der REST-Schnittstelle.
accept-Header Anforderungen, die SharePoint-Metadaten zurückgeben Gibt das Format für Antwortdaten vom Server an. Das Standardformat ist application/atom+xml. Beispiel: "accept":"application/json;odata=verbose"
content-type-Header POST-Anforderungen, die Daten im Anforderungstextkörper senden Gibt das Format der Daten an, die der Client an den Server sendet. Das Standardformat ist application/atom+xml. Beispiel: "content-type":"application/json;odata=verbose"
content-length-Header POST-Anforderungen, die Daten im Anforderungstextkörper senden (außer SP.RequestExecutor-Anforderungen) Gibt die Länge des Inhalts an. Beispiel: "content-length":requestBody.length
IF-MATCH-Header POST-Anforderungen für DELETE-, MERGE- oder PUT-Vorgänge, in erster Linie, um Listen und Bibliotheken zu ändern Bietet eine Möglichkeit, zu überprüfen, dass das Objekt, das geändert wird, seit seinem letzten Abruf nicht geändert wurde. Sie können aber auch festlegen, dass alle Änderungen überschrieben werden, wie im folgenden Beispiel zu sehen: "IF-MATCH":"*"
X-HTTP-Method-Header POST fordert DELETE-, MERGE- oder PUT-Vorgänge an Wird verwendet, um festzulegen, dass die Anforderung einen Aktualisierungs- oder Löschvorgang durchführt. Beispiel: "X-HTTP-Method":"PUT"
binaryStringRequestBody SP.RequestExecutor- POST-Anforderungen, die binäre Daten im Anforderungstextkörper senden Gibt an, ob der Anforderungstextkörper eine binäre Zeichenfolge ist. Boolean.
binaryStringResponseBody SP.RequestExecutor-Anforderungen, die binäre Daten zurückgeben Gibt an, ob die Antwort eine binäre Zeichenfolge ist. Boolean.

Unterstützung für Batchaufträge

Der SharePoint Online-REST-Dienst (sowie der REST-Dienst von lokalem SharePoint 2016 und höher) unterstützt die Kombination mehrerer Anforderungen in einem einzelnen Dienstaufruf mithilfe der OData-Abfrageoption $batch. Einzelheiten und Links zu Codebeispielen finden Sie unter Erstellen von Batchanforderungen mit den REST-APIs.

Siehe auch