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

ODATA VS RESTAPI : QUELLES SONT LES DIFFERENCES ?

6 minutes de lecture

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 définit les meilleures pratiques API REST

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. On retrouvera ainsi :

  • Les entités comme par exemple “client” ou “employé”. Elles sont définies par des types d’entité qui sont structurés grâce à une clef 
  • Un ensemble d’entités 
  • Des opérations, soit une exécution logique d’une partie d’un modèle donnée 
  • Des propriétés

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.

Communiquez entre un système et une application avec OData

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

En termes de transfert de données, la principale différence réside dans le fait que sur OData, il est possible de transférer des données ATOM en plus des données XML et JSON. Nous pouvons caractériser ATOM comme la nouvelle génération de données XML

Habituellement, on le rapproche à la notion de flux, soit plusieurs entrées. C’est ce qui permet à OData d’être aussi extensible. En effet, il est possible d’intégrer une balise qui n’existait pas auparavant. Il suffira d’en déclarer au préalable le schéma pour pouvoir ensuite l’utiliser.

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.

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.

Les derniers articles publiés :

LA GOUVERNANCE D’ENTREPRISE

Gérer une entreprise, c’est bien, le faire de manière éthique, c’est encore mieux. La gouvernance d’entreprise est un pôle important

La gestion des risques requiert un grand travail dans leur identification et leur évaluation. Toutes les entreprises sont confrontés à des risques

Gérer une entreprise, c’est bien, le faire de manière éthique, c’est encore mieux. La gouvernance d’entreprise est un pôle important de la

De plus en plus d’entreprise se voient dans l’obligation de réaliser des controles internes pour protéger les actifs et prévenir les risques.

L’ERP et le CRM permettent le gestion et l’échange des donnée des entreprise mais sont sensiblement différents par le fait que le

Retour haut de page