Partager via

Choisir l’ensemble d’API approprié dans SharePoint

  • Article

En savoir plus sur les ensembles d'API fournis dans SharePoint, y compris le modèle objet serveur, les différents modèles objet client et le service web REST/OData.

Facteurs permettant de déterminer l’ensemble d’API à utiliser

Vous pouvez choisir parmi plusieurs ensembles d'API pour accéder à la plateforme SharePoint. Leur utilisation dépend des facteurs suivants :

  • Le type d’application Les possibilités incluent, sans s’y limiter, les catégories suivantes, qui ne s’excluent pas mutuellement : un complément SharePoint, un composant WebPart sur une page SharePoint, une application Silverlight s’exécutant sur un ordinateur client ou un appareil mobile client, une application ASP.NET exposée dans SharePoint par un IFrame, JavaScript s’exécutant dans une page de site SharePoint, une page d’application SharePoint, une application Microsoft .NET Framework s’exécutant sur un ordinateur client, un script Windows PowerShell et un travail du minuteur s’exécutant sur un serveur SharePoint.
  • Vos compétences existantes. Aussi surprenant qu'il soit, vous pouvez créer des applications dans SharePoint sans devoir dominer nécessairement la programmation SharePoint. Vous pouvez passer directement au développement SharePoint si vous maîtrisez l'un des modèles de programmation suivants :
    • JavaScript
    • ASP.NET
    • REST/OData
    • .NET Framework
    • Windows Phone
    • Silverlight
    • Windows PowerShell
  • Le dispositif sur lequel le code s'exécute. Les possibilités incluent un serveur dans la batterie de serveurs SharePoint, un serveur externe tel qu'un serveur dans le nuage, un ordinateur client et un appareil mobile. Cette rubrique offre une vue d'ensemble des différents ensembles d'API fournis par SharePoint. La figure 1 indique les ensembles d'API pouvant être utilisés pour développer les 13 applications communes liées à SharePoint. Vous pouvez choisir parmi plusieurs API pour de nombreuses applications.

Figure 1. Types d’extension SharePoint et ensembles d’API SharePoint sélectionnés

Diagramme de Venn des ensembles d’API et des types d’application SharePoint

Le tableau suivant fournit des indications sur les ensembles d'API à utiliser pour une liste de projets d'extensibilité communs SharePoint sélectionnés. Les autres sections de cette rubrique décrivent les différents ensembles d’API existants.

Pour faire ceci... ... utilisez ces API
Créer une application web ASP.NET qui effectue des opérations de création/lecture/mise à jour/suppression (CRUD) dans un pare-feu sur les données SharePoint ou les données externes exposées dans SharePoint par un type de contenu externe Microsoft Business Connectivity Services (BCS). Modèle objet client JavaScript
Créer une application web ASP.NET qui effectue des opérations CRUD sur les données SharePoint ou les données externes exposées dans SharePoint par un type de contenu externe BCS, sans avoir à appeler SharePoint dans un pare-feu. Modèle objet client .NET Framework, modèle objet client Silverlight ou points de terminaison REST/OData
Créer une application web LAMP qui effectue des opérations CRUD sur les données SharePoint ou externes exposées dans SharePoint par un type de contenu externe BCS. Points de terminaison REST/OData
Créer une application Windows Phone qui effectue des opérations CRUD sur les données SharePoint Modèle objet client mobile
Créer une application Windows Phone qui utilise le service de notifications Push Microsoft (WNS) pour signaler les événements dans SharePoint par appareil mobile. Modèle objet client mobile et modèle objet serveur
Créer une application iOS ou Android qui effectue des opérations CRUD sur les données SharePoint Points de terminaison REST/OData
Créer une application .NET Framework qui effectue des opérations CRUD sur les données SharePoint Modèle objet client .NET Framework
Créer une application Silverlight qui effectue des opérations CRUD sur les données SharePoint Modèle objet client Silverlight
Créer une application HTML/JavaScript qui effectue des opérations CRUD sur les données SharePoint Modèle objet client JavaScript
Créer une Complément Office qui fonctionne avec SharePoint Modèle objet client JavaScript
Créer une commande Windows PowerShell personnalisée Modèle objet serveur
Créer un travail du minuteur Modèle objet serveur
Créer une extension de l’administration centrale Modèle objet serveur
Créer la cohérence de la marque dans l’ensemble d’une batterie de serveurs SharePoint Modèle objet serveur
Créer un composant WebPart, une page d’application ou un contrôle utilisateur ASP.NET personnalisé Modèle objet serveur
Important : si la fonctionnalité que vous souhaitez offrir aux clients n’est pas orientée vers l’administration SharePoint à une portée s’étendant au-delà de la collection de sites, nous vous recommandons de créer un complément SharePoint incluant une application web ASP.NET à distance avec des composants WebPart et des contrôles utilisateur personnalisés si nécessaire, au lieu d’utiliser le modèle objet serveur. Reportez-vous aux deux premières lignes de ce tableau.

Modèle objet serveur

Le plus grand ensemble d'API se trouve dans le modèle objet serveur de classes managées. En ce qui concerne SharePoint Foundation 2013, ce modèle objet inclut des classes et des membres qui permettent un contrôle programmatique de la structure de base du site et de la liste SharePoint Foundation. La plupart de ces classes se trouvent dans l’espace de noms Microsoft.SharePoint . En outre, vous pouvez étendre presque tous les composants SharePoint Foundation à l’aide du modèle objet serveur, y compris les flux de travail, les alertes, les composants WebPart, la recherche de base et Microsoft Business Connectivity Services (BCS). Le modèle objet serveur comprend également un ensemble complet d'API permettent des extensions de l'administration et du système de sécurité de SharePoint Foundation, notamment la sauvegarde, l'intégrité et les diagnostics de la batterie de serveurs, la journalisation, la gestion d'application web et batterie de serveur, la mise à niveau, le déploiement, la mise en cache et la personnalisation de Windows PowerShell.

En ce qui concerne SharePoint, de nombreuses classes sont ajoutées pour permettre la programmation de la gestion de contenu d’entreprise (ECM), des profils utilisateur, de la taxonomie, de la recherche avancée et d’autres fonctionnalités de SharePoint.

Vous pouvez utiliser LINQ to Objects pour interroger une collection IEnumerable en mémoire, mais un fournisseur LINQ to SharePoint permet l’interrogation directe des listes dans les bases de données de contenu SharePoint. À proprement parler, ce fournisseur n’est disponible avec aucun autre ensemble d’API abordé dans cette rubrique ; Toutefois, il existe des façons d’utiliser la syntaxe LINQ dans la plupart des autres.

Les assemblys qui définissent les classes côté serveur intégrées sont installés dans le Global Assembly Cache de chaque serveur lorsque SharePoint est installé. Lorsque vous programmez le modèle objet serveur, vos assemblys sont installés comme des solutions de batterie de serveurs dans le Global Assembly Cache.

Remarque

Il est préférable de développer des compléments SharePoint plutôt que de nouvelles solutions bac à sable dans SharePoint, mais des solutions bac à sable peuvent quand même être installées dans des collections de sites sur SharePoint. Les assemblys de ces solutions restent dans le package à moins d’être en cours d’utilisation, auquel cas ils sont temporairement installés dans un dossier du serveur. Pour plus d’informations, consultez Où sont déployés les assemblys dans les solutions en bac à sable ?.

Limitations de votre utilisation du modèle objet serveur

La logique personnalisée dans Compléments SharePoint est toujours distribuée « vers le bas » pour le client ou « vers le haut » dans le nuage (ou « sur » un serveur en dehors de la batterie de serveur SharePoint). Dans tous ces modèles de distribution, l'un des modèles objets client ou les points de terminaison REST/OData doivent être utilisés. (Vous ne pouvez pas utiliser le modèle objet serveur dans une Complément SharePoint.) Par exemple, si l'application contient des pages SharePoint hébergées, celles-ci peuvent accéder aux données SharePoint à l'aide du modèle objet client JavaScript. Ces pages peuvent également exposer les applications Silverlight qui utilisent le modèle objet client SharePoint Silverlight. Pour plus d’informations sur les compléments SharePoint, voir Aspects importants de l’architecture et du développement des compléments SharePoint.

Modèles objet client pour le code managé

SharePoint possède trois modèles objet client pour le code managé : .NET, Silverlight et mobile.

Modèle objet client .NET

Le modèle objet SharePoint pour .NET Framework est utilisé dans les applications .NET Framework qui s'exécutent sur un client Windows sans téléphone. L'un des éléments suivants compte en tant que client :

  • L'ordinateur d'un utilisateur
  • Un serveur externe à la batterie SharePoint
  • Un rôle web ou rôle de travail sur Microsoft Azure

Presque toutes les classes du modèle objet serveur de site et de liste ont une classe correspondante dans le modèle objet client .NET Framework. Par ailleurs, le modèle objet client .NET Framework propose un ensemble complet d’API visant à étendre les autres fonctionnalités, notamment certaines fonctionnalités SharePoint comme ECM, la taxonomie, les profils utilisateur, la recherche avancée, l’analyse, BCS, etc.

Pour améliorer les performances, des lignes de code écrites en conséquence dans le modèle objet client .NET Framework sont envoyées au serveur SharePoint par lots, où elles sont converties en code côté serveur, puis exécutées. Les résultats de requête et le nouvel état de toutes les variables sont alors renvoyés au client. En tant que développeur, vous devez déterminer si un lot s'exécute de manière synchrone ou asynchrone. (Dans un lot synchrone, les applications .NET Framework attendent les résultats renvoyés par le serveur avant de continuer ; dans un lot asynchrone, le traitement côté client continue immédiatement et l'interface utilisateur du client (UI) reste réactive.)

Vous pouvez utiliser la syntaxe de requête LINQ dans votre code client pour interroger n’importe quel objet IEnumerable , y compris les objets SharePoint qui implémentent IEnumerable. Toutefois, lorsque vous effectuez cette opération, vous utilisez LINQ to Objects, et non le fournisseur LINQ to SharePoint. La documentation de ce dernier n’est donc pas pertinente pour le code côté client.

Les assemblys pour le modèle d’objet client .NET Framework doivent être installés sur le client. Ils sont inclus dans un package redistribué que vous pouvez obtenir sur les composants clients SharePoint.

Pour obtenir des exemples d’utilisation du modèle objet .NET Framework, consultez Effectuer des opérations de base à l’aide du code de la bibliothèque cliente SharePoint.

Remarque

Vous pouvez également utiliser les points de terminaison REST/OData SharePoint dans une application .NET Framework. Pour une comparaison du modèle objet client .NET Framework avec les points de terminaison REST/OData SharePoint, consultez la section Points de terminaison REST/OData plus loin dans cet article.

Modèle objet client Silverlight

Le modèle objet SharePoint pour Silverlight est utilisé dans les applications Silverlight, indépendamment de l'endroit où le fichier XAP compilé est conservé. Il peut se trouver dans une bibliothèque de biens sur un site web SharePoint, sur un ordinateur client, dans le stockage en nuage ou sur un serveur externe. En règle générale, une application Silverlight est exposée dans SharePoint dans un objet SilverlightWebPart . Le modèle objet client Silverlight dans SharePoint est presque identique à celui dans .NET Framework, et inclut la prise en charge des mêmes zones d'extensibilité. La principale différence réside dans la version Silverlight : tous les lots de commandes sont envoyés au serveur de manière asynchrone, de sorte que l'interface utilisateur de l'application reste active.

Les assemblys du modèle objet client Silverlight sont conservés sur chaque serveur SharePoint sous %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS\ClientBin. Ils n'ont pas à être installés sur l'ordinateur qui exécute l'application Silverlight, mais vous avez la possibilité de le faire. En outre, vous pouvez les regrouper dans le fichier Xap de l'application.

Vous pouvez inclure les fichiers Xap Silverlight dans les Compléments SharePoint, y compris les applications SharePoint hébergées, auquel cas le fichier Xap est déployé sur une bibliothèque dans le site web d'application. (Pour plus d'informations sur les applications web, voir Héberger des sites web, des sites web de complément et des composants SharePoint dans SharePoint.) Les applications Silverlight constituent un moyen utile d'inclure du code personnalisé SharePoint dans une application, étant donné que le code personnalisé côté serveur n'est pas autorisé dans les Compléments SharePoint. (Pour plus d’informations sur les sites web d’application, voir Héberger des sites web, des sites web de complément et des composants SharePoint dans SharePoint.) Cela fait d’une application Silverlight un moyen utile d’inclure du code SharePoint personnalisé dans une application, car le code côté serveur personnalisé n’est pas autorisé dans les compléments SharePoint. Il permet également aux développeurs Silverlight d’utiliser leurs compétences existantes pour créer des applications SharePoint avec une courbe d’apprentissage minimale.

Remarque

Vous pouvez également utiliser les points de terminaison REST/OData SharePoint dans une application Silverlight. Pour une comparaison du modèle objet client Silverlight avec les points de terminaison REST/OData SharePoint, consultez la section Points de terminaison REST/OData plus loin dans cet article.

Modèle objet mobile

Une version spéciale du modèle objet client Silverlight est disponible pour les appareils Windows Phone. Il inclut des API supplémentaires qui s’appliquent uniquement aux téléphones, telles que les API qui permettent à une application de téléphone de s’inscrire aux notifications du service de notification Push Microsoft. Il prend en charge toutes les fonctionnalités principales de SharePoint ; Toutefois, il ne prend pas en charge les zones d’extensibilité non principales prises en charge par les deux autres modèles objet clients pour le code managé. Pour accéder à ces zones supplémentaires, utilisez les points de terminaison REST/OData SharePoint dans votre application mobile. Consultez la section Points de terminaison REST/OData plus loin dans cet article.

Les assemblys du modèle objet mobile sont conservés sur chaque serveur SharePoint à l’emplacement %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS\ClientBin. Créez un package pour le fichier Xap de votre application Windows Phone.

Modèle objet JavaScript

SharePoint fournit un modèle objet JavaScript à utiliser dans un script en ligne ou des fichiers .js distincts. Il propose les mêmes fonctionnalités que les modèles objet client .NET Framework et Silverlight. Comme le modèle objet client Silverlight, le modèle objet JavaScript est un moyen utile d’inclure du code SharePoint personnalisé dans une application, car le code côté serveur personnalisé n’est pas autorisé dans les compléments SharePoint. Il permet également aux développeurs web d’utiliser leurs compétences JavaScript existantes pour créer des applications SharePoint avec une courbe d’apprentissage minimale.

Comme les modèles objet client de code managé, l'infrastructure JavaScript de SharePoint interagit avec les serveurs de la batterie de serveurs dans les lots. Ces lots sont toujours exécutés de façon asynchrone. En outre, il est désormais possible d'accéder aux données SharePoint sur plusieurs domaines dans JavaScript (uniquement les données situées dans la même collection de site parente), ce qui n'était pas autorisé dans les versions précédentes de SharePoint. Pour plus d’informations, consultez la rubrique Accéder à des données SharePoint à partir de compléments à l’aide de la bibliothèque inter-domaines. Les données sont renvoyées par le serveur dans JavaScript Object Notation (JSON).

Le modèle objet JavaScript est défini dans un ensemble de fichiers *.js situés dans %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS sur chaque serveur.

Pour obtenir des exemples d’utilisation du modèle objet .NET Framework, voir Effectuer des opérations de base à l’aide du code de bibliothèque JavaScript dans SharePoint.

Remarque

Vous pouvez également utiliser les points de terminaison REST/OData SharePoint dans une application JavaScript. Pour une comparaison du modèle objet client JavaScript avec les points de terminaison REST/OData de SharePoint, consultez la section suivante, Points de terminaison REST/OData.

Points de terminaison REST/OData

Pour les scénarios dans lesquels vous devez accéder à des entités SharePoint à partir de technologies clientes qui n’utilisent pas JavaScript et ne sont pas basées sur les plateformes .NET Framework ou Silverlight, SharePoint fournit une implémentation d’un service web REST (Representational State Transfer) qui utilise le protocole OData pour effectuer des opérations CRUD sur les données de liste SharePoint. En outre, pratiquement chaque API dans les modèles objets clients présente un point de terminaison REST correspondant. Cela permet à votre code d'interagir directement avec les artefacts SharePoint en utilisant une technologie prenant en charge les requêtes et réponses HTTP standard. Pour utiliser les fonctionnalités REST intégrées dans SharePoint, votre code crée une requête HTTP RESTful vers un point de terminaison correspondant à l'API du modèle objet client souhaité. Le service web .svc client traite la requête HTTP et envoie une réponse au format Atom ou JSON.

Pour plus d’informations sur l’utilisation du service web REST/OData, consultez le nœud Utiliser les opérations de requête OData dans les requêtes REST SharePoint ; Pour obtenir des exemples, consultez la rubrique Effectuer des opérations de base à l’aide de points de terminaison REST SharePoint.

Comparaison de la programmation REST/OData avec la programmation de modèle objet client

Dans certains cas, il peut être préférable d'utiliser des points de terminaison REST même dans les applications pour lesquelles un modèle objet SharePoint est disponible, en particulier pour les développeurs n'ayant pas d'expérience de développement Windows. Le tableau suivant présente une comparaison des principales fonctionnalités de ces choix de programmation pour un développeur créant une application sur une plateforme Windows ou avec une plateforme qui prend en charge JavaScript.

Fonctionnalité Modèles objet .NET Framework ou Silverlight Modèle objet JavaScript Points de terminaison REST/OData appelés à partir d’une plateforme Windows ou JavaScript
Programmation orientée objet Oui Oui Non
Traitement par lots Oui Oui Oui
API de traitement conditionnel et de gestion des exceptions Oui Non Non
Disponibilité de la syntaxe LINQ Oui Non Non
Combinaison de données de liste à partir de différentes applications web SharePoint Oui Non Oui
Connaissance par les développeurs REST/OData expérimentés Non Non Oui
Similarité avec la programmation non Windows ou JavaScript Non Oui Oui
Typage fort des champs d’élément de liste Non (sauf avec LINQ) Non Oui, à partir de la plateforme Windows ; Non, à partir de JavaScript
Utilisation de jQuery, Knockout et autres bibliothèques JavaScript Non Oui Non, à partir de la plateforme Windows ; Oui, à partir de JavaScript

Infrastructure WCF Data Services

Si vous préférez utiliser la syntaxe LINQ dans les applications clientes .NET Framework ou Silverlight, SharePoint prend en charge WCF Data Services en tant que fournisseur LINQ. Vous pouvez cibler listdata.svc (pour les données de liste uniquement) comme dans les versions antérieures de SharePoint Foundation ou le même client.svc prenant en charge l'interface OData pour l'accès à toutes les entités SharePoint, outre la liste de données. Pour plus d'informations, voir Effectuer des requêtes sur SharePoint Foundation avec ADO.NET Data Services.

La figure 2 illustre la relation entre les différentes API clientes, divers types d’applications clientes et SharePoint. Les différentes URL _api sont celles liées à la batterie de serveur des points de terminaison REST. Pour plus d’informations, consultez la rubrique Mise en route du service REST SharePoint 2015.

Figure 2. Applications clients et API dans SharePoint

Modèle de programmation des applications pour SharePoint

Ensembles d’API déconseillées

Deux ensembles d’API sont toujours pris en charge dans l’infrastructure SharePoint à des fins de compatibilité descendante, mais nous vous recommandons de ne pas les utiliser pour les nouveaux projets : les services web ASP.NET (asmx) et les appels de procédure distante (RPC) directs vers le fichier owssvr.dll .

Voir aussi