Le protocole OData définit les meilleures pratiques pour consommer les API REST. Flexible, il facilite le développement et l’échange de données sécurisées entre des solutions hybrides
11/05/2022
QUELLE SONT LES DIFFERENCES ENTRE ODATA ET API REST ?
6 minutes de lecture
Table des matières
Un projet ? Une question ?
Laissez-nous vos coordonnées pour qu’un de nos experts vous recontacte très rapidement
Ces dernières années ont vu le développement de très nombreuses applications SaaS ce qui a conduit dans le même temps à la mise en avant de plus en plus d’API REST.
Ce développement de grande ampleur se fait si rapidement qu’aujourd’hui, les développeurs passent presque plus de temps sur les API que sur la mise en place de leur propre application.
Avec son protocole OData, Microsoft a souhaité régler ce problème et faciliter le travail des développeurs face aux API.
Les deux interfaces vont donc s’unir pour communiquer et échanger des données malgré des normes et protocoles différents au sein d’une organisation utilisatrice d’une ou plusieurs applications SAP.
Nous allons tenter de comprendre un peu mieux les différences et surtout les enjeux de tout cela à travers cet article.
OData, qu’est-ce que c’est ?
OData est la contraction de l’expression Open Data Protocol. Il s’agit d’un protocole technique qu’il ne faut pas confondre avec l’Open Data qui correspond à l’accès libre et l’usage de certaines données pour n’importe quel utilisateur, SAP ou non.
Pour faire simple, on peut dire que OData est un standard OASIS qui définit les meilleures pratiques pour créer et consommer des APIs RESTful.
Comme pour ces dernières, REST est le composant principal OData. Nous reviendrons plus en détail sur cela dans la suite de l’article. La version actuelle 4.0 date de 2013.
OData a la particularité de posséder un encodage ATOM. Pour rappel, ATOM est un éditeur de texte développé par GitHub pour les développeurs basé sur le format XML.
En plus de cela, OData supportera aussi le format JSON pour représenter les ressources qu’il expose, souvent le SAP Gateway (SAP GW) server ou add-on.
Pour décrire les données exposées dans un service OData, il convient de se baser sur un haut niveau du modèle de données d’entité (EDM).
On considérera qu’une ressource OData correspond à tout élément du modèle qu’il sera possible d’échanger et d’adresser. Les ressources sont généralement représentées sous forme d’entités ou de collections d’entités.
Une entité représente une instance unique d’un type d’objet et est identifiée par une clé primaire. Par exemple, dans une base de données de clients, une entité pourrait représenter un client spécifique avec des propriétés telles que son nom, son adresse, son numéro de téléphone, etc.
Une collection d’entités est un ensemble d’instances d’un type d’objet particulier. Par exemple, une collection de clients pourrait inclure toutes les instances de clients dans la base de données.
Les ressources OData peuvent être manipulées par le client en utilisant les opérations HTTP standard, telles que GET, POST, PUT et DELETE. Par exemple, un client peut récupérer une collection d’entités en envoyant une requête HTTP GET au serveur OData avec l’URL appropriée pour la collection. Le serveur OData renvoie alors les entités sous forme de données JSON ou XML dans le corps de la réponse HTTP.
Une API REST, qu'est-ce que c'est ?
Une API ou Application Program Interface est un ensemble de définitions et de protocoles que l’on va utiliser pour développer ou intégrer un logiciel dans une application.
En réalité, cela permet à deux ou plusieurs logiciels de communiquer à travers un ensemble de règles précises, qu’ils aient le même langage ou non. Mais ce ne sont pas des applications en tant que telles.
En effet, seuls les développeurs y auront accès et pourront faire fonctionner cet outil. Un utilisateur lambda ne verra que le résultat.
Aujourd’hui par exemple, de nombreux sites et applications proposent de s’inscrire directement grâce à son compte Google ou Facebook. Cela n’est possible que grâce à une API.
Il existe plusieurs types d’API : REST, SOAP… Ici, nous nous intéresserons plus précisément aux API REST. Néanmoins, si vous souhaitez en savoir plus sur les API, n’hésitez pas à aller lire notre article dédié.
Le terme REST (Representational State Transfer) a été mis en avant au début des années 2000 par Roy Fielding, connu pour être un des auteurs principaux de la spécification HTTP.
Un service REST n’est pas une architecture mais un ensemble de restrictions que l’on devra prendre en compte dans l’architecture logicielle que l’on va utiliser lors de la création d’application web HTTP.
Le défi sera donc d’aligner cette nouvelle architecture avec celle existante dans le paysage SAP. Cette technologie est basée sur le transfert avec l’utilisation de moins de bandes passantes généralement construites en Javascript ou encore Python.
Les API Rest permettent le développement des applications informatiques de par l’utilisation de quatre opérations de base ou requêtes HTTP permettant d’accéder aux données et de les utiliser.
On peut préciser qu’il sera possible de l’associer à un type de requête SQL et une méthode HTTP. Voici un récapitulatif des opérations :
- CREATE (SQL: INSERT / HTTP : PUT / POST) : permet la création de ressources
- READ (SQL: SELECT / HTTP : GET) : permet la récupération d’une ressource ou d’une collection
- UPDATE (SQL: UPDATE / HTTP : PUT / PATCH) : modifie ou remplace une ressource
- DELETE (SQL: DELETE / HTTP : DELETE) : supprime une ressource ou une collection
En pratique, nous utilisons tous de nombreuses API REST tous les jours, que ce soit avec les différents plugins que nous installons sur nos navigateurs ou quand nous utilisons (même sans le savoir) des services externes depuis un système d’application ou une autre application SAP ou Cloud.
Aujourd’hui, la plupart des API se trouvent sur des plateformes SaaS (Software as a service) même si quelques-unes existent sur des Paas (Platform as a service). Cela implique pour les entreprises souhaitant proposer des API REST de pouvoir offrir l’ensemble des fonctionnalités liées au Cloud avec notamment un outil d’intégration Cloud qui fournit des connecteurs et des fonctionnalités API Rest.
Quelles sont les Différences entre API REST et OData ?
Différences entre les principes de conception
API REST et OData possèdent des principes propre qui les différencient.
Les API REST ont six principes ou contraintes qu’il faut absolument respecter. Nous allons mettre en avant ceux-ci.
L’obligation de donner un identifiant à tous les éléments : Sur Internet, il existe un concept d’identification grâce à l’URI. L’URI est tout simplement un élément (une suite de chiffres par exemple) permettant d’identifier une ressource.
Lier les éléments entre eux : ce principe fait référence à l’HATEOS (Hypermedia As The Engine of Application State Hypermédia). Il est important de rappeler que le jugement de conformité d’une API peut se réaliser grâce au modèle de Richardson composé de quatre niveaux.
- Niveau 0 : RPC : on parle ici du Swamp of POX. Il s’agit de l’utilisation simple du HTTP. On aura un seul point d’entrée, soit une seule URI. De plus, la seule action réalisée sera une action POST (normalement réservée à la création de ressource). Si l’API se situe à ce niveau, elle ne sera pas REST mais plutôt SOAP. En effet, nous avons vu plus haut que chaque ressource devait avoir son point d’entrée
- Niveau 1 : utilisation des ressources. Dans ce cas, chaque ressource aura son endpoint. A noter qu’ici, l’ensemble des requêtes continuent de se faire en POST
- Niveau 2 : l’utilisation des verbes HTTP, soit les verbes CRUD vus précédemment. L’action ne fait alors plus partie de l’URI. C’est également à cette étape là que va se mettre en place le code status. (code qui indique si la requête HTTP a été effectuée avec succès ou non). On pourra par exemple retrouver le code 200 pour une requête réussie ou encore la fameuse erreur 404 pour une ressource qui n’a pas été trouvée.
- Niveau 3 : il s’agit du niveau HATEOS qui n’est pas souvent atteint par la plupart des API. Il s’agit de mettre en avant des liens que pourront suivre les utilisateurs pour atteindre leur but. Ainsi, ces derniers seront guidés sur ce qu’ils doivent faire et n’auront pas besoin de lire toute la documentation de l’API.
Utiliser les méthodes standard : toutes les ressources pour être utilisées par SAP, doivent avoir la même interface et doivent surtout répondre aux méthodes standards ou autrement dit, aux verbes HTTP. En plus de GET ou POST, on retrouve également HEAD, DELETE ou encore OPTION.
Avoir des représentations multiples pour les ressources : il faut savoir comment traiter les données reçues. Grâce à l’approche HTTP, un client qui sait interagir dans un format spécifique peut interagir avec n’importe quelle ressource qui peut proposer une représentation dans ce format.
Communiquer sans état : on considère que l’API REST n’a pas d’état, c’est à dire que les différents serveurs ne doivent pas conserver de trace des contextes de communication.
Une communication ou un transfert de données SAP est unique et le contexte doit se limiter à la simple requête. Cela s’explique par le nombre de clients qui utilisent l’API en même temps. Si elles devaient conserver quelque chose de chaque requête, la charge mémoire serait fortement impactée.
Code à la demande : cette contrainte est optionnelle. Il s’agit de donner la possibilité aux utilisateurs de télécharger du code exécutable. Ce dernier pourra donc par exemple télécharger un javascript ou même une application flash pour crypter les communications.
De son côté, OData utilise tous les principes REST et a en plus l’avantage d’être flexible et de pouvoir s’adapter à l’utilisation que l’on en a.
Différences dans les transferts de données
Dans une API REST, les données sont généralement transférées en utilisant le protocole HTTP et les verbes HTTP (GET, POST, PUT, DELETE). Les données sont souvent transférées sous forme de JSON (JavaScript Object Notation) ou XML (eXtensible Markup Language).
Lorsqu’un client interroge une API REST, il envoie une requête HTTP au serveur en utilisant l’URI de la ressource souhaitée et l’opération HTTP appropriée. Le serveur renvoie ensuite les données demandées dans le corps de la réponse HTTP. Le client peut utiliser les informations contenues dans la réponse pour afficher ou manipuler les données.
Dans OData, les données sont également transférées en utilisant le protocole HTTP et les verbes HTTP, mais avec des fonctionnalités supplémentaires. OData ajoute des fonctionnalités pour faciliter la manipulation de données, telles que la pagination, le tri, le filtrage et l’agrégation. Ces fonctionnalités sont disponibles via des paramètres d’URL spécifiques.
OData utilise également un format de données spécifique, appelé JSON-LD (JSON Linked Data), qui permet d’ajouter des informations sémantiques aux données. Cela permet aux clients de comprendre le contexte des données et d’utiliser ces informations pour effectuer des opérations plus avancées.
Différences entre les fonctions
Comme nous l’avons dit précédemment, la fonction principale d’une API REST est d’envoyer des messages entre client et serveur via HTTP grâce aux requêtes basiques CRUD. Grâce à OData, il est également possible d’envoyer des messages via HTTP. Enfin, la principale différence réside dans l’exposition de métadonnées. On en distingue deux différentes :
- Le service document qui reprend le protocole ATOM
- Un document XML décrivant le modèle de données (structure, liens…)
Le langage utilisé pour ces métadonnées se nomme Conceptual Schema Definition Language (CSDL).
Que choisir entre API REST et OData ?
Le choix entre API Rest et OData se fera toujours en fonction de vos besoins et de ce que vous voulez réellement faire grâce à cela. Ainsi, pour de la récupération de données (comme le web scraping ou la récupération de données grâce à l’URL), nous vous conseillons presque toujours de privilégier les API Rest pour leur rapidité et leur facilité d’utilisation.
En revanche, OData semble plus adaptée lors d’une communication entre un système et une application. De plus, son extensibilité est synonyme de personnalisation et donc de capacité plus importante à répondre à vos besoins. Si ces derniers sont très spécifiques, OData est la technologie qu’il vous faut.
En effet, Les API RESTful sont généralement plus axées sur les opérations CRUD (création, lecture, mise à jour, suppression), tandis qu’OData fournit un ensemble plus complet d’opérations d’accès et de modification des données.
De plus, OData permet de définir des options de requête et des opérations personnalisées qui peuvent être utilisées pour ajouter de nouvelles fonctionnalités à un service sans modifier l’implémentation du service sous-jacent. Les API REST, quant à elles, s’appuient généralement sur les méthodes HTTP standard pour fournir des fonctionnalités.
En résumé, alors que les API REST offrent un moyen simple et léger d’exposer des opérations CRUD sur HTTP, OData est un protocole plus complet pour l’interrogation et la mise à jour des données, avec un ensemble riche de fonctionnalités pour l’accès et la modification des données, des types et des relations complexes, des opérations personnalisées et une interrogation plus normalisée.
Le choix entre API Rest et OData se fera toujours en fonction de vos besoins et de ce que vous voulez réellement faire grâce à cela. Ainsi, pour de la récupération de données (comme le web scraping ou la récupération de données grâce à l’URL), nous vous conseillons presque toujours de privilégier les API Rest pour leur rapidité et leur facilité d’utilisation.
En revanche, OData semble plus adaptée lors d’une communication entre un système et une application. De plus, son extensibilité est synonyme de personnalisation et donc de capacité plus importante à répondre à vos besoins. Si ces derniers sont très spécifiques, OData est la technologie qu’il vous faut.
En effet, Les API RESTful sont généralement plus axées sur les opérations CRUD (création, lecture, mise à jour, suppression), tandis qu’OData fournit un ensemble plus complet d’opérations d’accès et de modification des données.
De plus, OData permet de définir des options de requête et des opérations personnalisées qui peuvent être utilisées pour ajouter de nouvelles fonctionnalités à un service sans modifier l’implémentation du service sous-jacent. Les API REST, quant à elles, s’appuient généralement sur les méthodes HTTP standard pour fournir des fonctionnalités.
En résumé, alors que les API REST offrent un moyen simple et léger d’exposer des opérations CRUD sur HTTP, OData est un protocole plus complet pour l’interrogation et la mise à jour des données, avec un ensemble riche de fonctionnalités pour l’accès et la modification des données, des types et des relations complexes, des opérations personnalisées et une interrogation plus normalisée.
Conclusion
OData possède donc un nombre important d’avantages par rapport à une API REST classique. Nous avons tout d’abord vu à quel point cette technologie était facile et intuitive à utiliser avec Java et n’importe quel autre langage de programmation permettant les échanges web.
C’est tellement simple que l’on peut même le faire depuis n’importe quel URL. En effet, lorsqu’on va écrire un URL, on va envoyer une information a OData qui va répondre en XML. De plus, on préférera souvent OData pour son extensibilité permettant une adéquation parfaite avec l’ensemble de vos besoins.
Découvrir plus d’articles VASPP
Tout savoir sur les Data Lake : Avantages, Fonctionnalités et Meilleures Pratiques
Tout savoir sur les Data Lake : leur utilité, avantages et meilleures pratiques pour stocker et gérer des données massives efficacement. Optimisez votre infrastructure de
SAP Integration Suite (SCPI) : quelles sont ses Fonctionnalités
SAP CPI ou SCPI, le middleware intégré à SAP BTP permet de développer des API et offre un catalogue de connecteurs permettant une orchestration des
Qu’est-ce qu’une API (Interface de Programmation) ?
Découvrez ce qu’est une API (Interface de Programmation) et comment elle permet la communication et l’échange de données entre différentes applications informatiques. Cet article explique
