SharePoint offers multiple types of APIs:
REST APIs - Allow access and manipulation of SharePoint resources using simple HTTP calls. These perform CRUD operations on SharePoint items like lists, documents, and sites.
Client-Side Object Model (CSOM) - Provides libraries for languages like JavaScript, .NET, and Silverlight to interact with SharePoint.
JavaScript Object Model (JOM) - Similar to CSOM but specific to JavaScript, used for creating dynamic interfaces.
SOAP Web Services - Allow communication with SharePoint through XML-based protocols, though less commonly used now.
The REST APIs are a prominent type in SharePoint:
They follow REST architectural principles, using HTTP methods (GET, POST, PUT, PATCH, DELETE) to perform operations on resources identified by URLs.
They offer flexibility and ease of use, working with both structured and unstructured data efficiently.
Security is handled through OAuth and access tokens.
They are context-independent and scalable.
There is a close relationship between SharePoint APIs and Microsoft Graph API:
Microsoft Graph provides a unified gateway to access data and services across Microsoft 365, including SharePoint.
It allows developers to access SharePoint functionalities using the same endpoints and authentication tokens as other Microsoft 365 services.
This integration simplifies interoperability between SharePoint and other Microsoft 365 services.
Yes, the official SharePoint API does have webhooks. Here are the key points about SharePoint webhooks:
SharePoint webhooks enable developers to build applications that subscribe to receive notifications on specific events that occur in SharePoint. Currently, webhooks are only enabled for SharePoint list items.
SharePoint webhooks support the following asynchronous list item events:
It's important to note that SharePoint webhooks only support asynchronous events, meaning they are fired after a change has occurred.
To create a webhook subscription, you need to provide the following information:
Unfortunately, it's not possible to subscribe to specific event types when creating a webhook. The webhook will trigger for all supported event types on the subscribed list.
Here's a basic example of how to add a webhook to a SharePoint list using the WebHookManager class:
public async Task<SubscriptionModel> AddListWebHookAsync(string siteUrl, string listId, string webHookEndPoint, string accessToken, int validityInMonths = 3) { // webhook add code... }
This method adds a webhook to a SharePoint list, requiring the site URL, list ID, webhook endpoint URL, access token, and optional validity period in months.
In summary, SharePoint webhooks provide a powerful way to receive notifications about changes in SharePoint lists, but they don't allow for subscribing to specific event types. Developers need to handle all event types in their webhook implementation and filter as needed in their application logic.
Here are the key points about API rate limits for the SharePoint API:
SharePoint Online uses throttling to limit excessive usage of resources [1].
When usage limits are exceeded, SharePoint throttles further requests from that client for a short period [5].
If an application continues to exceed limits, SharePoint may completely block it, returning HTTP 503 errors [5].
The maximum limit is 6000 calls per minute per tenant [5].
Limits are based on the number of licenses purchased per organization [5].
Every request across all API endpoints (Graph, CSOM, REST) counts towards an application's usage [5].
Limits apply per application within a tenant, but multiple applications share the same resource bucket [1].
There are no published limits across all apps for a single tenant [1].
Different APIs have different costs depending on complexity, normalized into "resource units" [1].
For intensive operations, implement handling of 429 errors and use a "backing off" algorithm [2].
Implement sleep time and batching of calls to avoid hitting limits [5].
Always check for 429 and 503 errors and use the Retry-After header to determine wait time before retrying [1].
Consider splitting load across multiple apps, but be aware that they still share tenant-wide resource limits [5].
For higher limits, contact Microsoft about additional licensing options [5].
In summary, while there are defined per-app limits, the exact interaction between different API types and tenant-wide limits is not fully documented. Careful API usage, error handling, and potentially working with Microsoft for higher limits are recommended approaches for high-volume scenarios.
Based on the search results provided, here is the most up-to-date information about the SharePoint API versions:
The most recent version of the SharePoint REST API is the one used in SharePoint Online and SharePoint Server 2019. This API is accessed through endpoints like:
https://{site_url}/_api/...
Key points:
Microsoft recently announced the general availability of the Microsoft Graph API for SharePoint Pages [2]. This API allows developers to programmatically interact with SharePoint Pages and News posts.
Key points:
In summary, while there isn't a specific version number mentioned for the SharePoint API, the most recent and recommended version is the one used in SharePoint Online and SharePoint Server 2019, with the addition of the new Microsoft Graph API for SharePoint Pages for cloud instances.
Apply for a Microsoft Developer account by visiting this link.
During the application process, you may be asked to specify your areas of interest. If presented with options, prioritize selections that include SharePoint, OneDrive, and Microsoft Graph.
Your sandbox account will be refreshed every 90 days as long as it remains in active use.
Create a site within your SharePoint account. You can choose either a Team or Communication site.
Populate your SharePoint sandbox account with data to work with.
Navigate to your developer account, then go to Azure Active Directory > App Registrations > + New Registration to create a new OAuth app.
If you're using Postman to test the integration, add the Postman URL as your redirect URI.
In your app registration, click on API permissions and then Add a permission.
Choose SharePoint from the list of APIs and select Delegated permissions.
Check the permissions you need for your app, such as Sites.Read.All or Sites.ReadWrite.All, and click Add permissions.
Click on Grant admin consent for <your organization> and confirm the consent.
In your app registration, click on Certificates & secrets and then New client secret.
Enter a description and an expiration date for your secret and click Add.
Copy the value of the secret and store it securely. You'll need it later.
Based on the search results provided, here is a list of data models that can be interacted with using the SharePoint API, along with what is possible for each:
It's important to note that the available operations and data models may vary depending on the specific API being used (REST, .NET Client Object Model, or JavaScript Object Model) and the SharePoint version. Additionally, some operations may require specific permissions or authentication methods.
