Présentation technique de la mise à niveau de l'API REST vers la v4

La version 4.0 de l'API REST apporte de nombreuses améliorations et optimisations par rapport à la version précédente (v2). L'API v4 assure la compatibilité en utilisant le même jeton d'accès que la v2, ce qui facilite la migration progressive de votre code vers la v4 tout en continuant à utiliser le jeton existant. Le préfixe du chemin pour l'API v4 est passé de « /api/v2 » à « /api/v4/ ». Bien que de nombreuses fonctions conservent leur nom et leur modèle, garantissant ainsi une transition simple de la « v2 » à la « v4 », certaines fonctions ont subi des modifications. Cette rubrique sert de guide technique et décrit les principales modifications introduites dans l'API v4.

Mise à niveau de la version OData

L'API utilise désormais OData v4 au lieu d'OData v3. Cette mise à niveau introduit des fonctionnalités avancées d'interrogation, notamment la prise en charge de puissantes agrégations de données.

Impact sur les utilisateurs :

  • Les utilisateurs peuvent exploiter des requêtes plus complexes pour une récupération précise des données.
  • Les requêtes existantes basées sur la syntaxe OData v3 doivent être mises à jour pour s'aligner sur la norme OData v4.
Voici quelques exemples de modifications entre OData v3 et v4 dans l'expression $filter :
  • substringof n'est plus disponible ; dans la v4, vous devriez utiliser contains à la place.
  • Le littéral GUID a été modifié : guid’971314e0-b891-4d2e-b672-0dc37885bb0a’971314e0-b891-4d2e-b672-0dc37885bb0a
  • Le littéral DateTime a été modifié : DateTime'2024-07-31T07:30:00' 2024-07-31T07:30:00z

Résultats de la page pour les fonctions de collecte

Les fonctions qui renvoient des collections offrent désormais un résultat en pages, qui inclut un nombre total facultatif.

Les réponses seront conformes au format suivant :

{
                "Items": [
                {
                Item1 ... 
                },
                {
                Item2 ... 
                }
                ],
                "Count": 2 //Optional - appears only if query option $count=true was provided 
                }

Dans l'API v2, de nombreuses fonctions qui renvoient une collection ont deux versions : l'une qui renvoie une collection d'objets et l'autre qui renvoie un résultat de page pour les objets. L'avantage du résultat en pages est que si $top et $skip sont utilisés pour récupérer une seule page, le nombre total des objets sera inclus avec les données, ce qui permettra d'enregistrer une demande supplémentaire pour le nombre.

Dans l'API v4, les fonctions qui renvoient directement des objets sont omises. Ces fonctions fournissent systématiquement des données au format PageResult. Le nombre est facultatif et n'est renvoyé que si $count=true est ajouté aux options de requête.

Par exemple, dans l'API v2, il existe deux fonctions - /api/V2/Apps, qui renvoie le résultat au format normal (tableau d'objets) et /api/V2/Apps/GetAsPage, qui renvoie le résultat au format de page avec le nombre.

Dans la v4, il n'y a qu'une seule fonction - /api/v4/Apps, qui renvoie le résultat au format de page, et le nombre est facultatif. Notez que si le nombre n'est pas nécessaire, il est plus efficace de ne pas le demander.

Suppression des fonctions redondantes

Les fonctions renvoyant des objets spécifiques ont été supprimées afin d'appliquer des filtres pour un ID d'objet spécifique aux fonctions renvoyant des collections.

Les fonctions qui regroupent les objets ne sont plus nécessaires, car cette fonctionnalité est désormais disponible à l'aide d'OData v4 ($apply query option).

Exemple :

GET /api/v2/Scans/CountByUser n'a pas été ajouté à la v4.

Les mêmes fonctionnalités peuvent être obtenues à l'aide de l'URL suivante :

GET /api/v4/Scans?$apply=groupby((CreatedBy/Id,CreatedBy/UserName,CreatedBy/FirstName,CreatedBy/LastName,CreatedBy/Email), aggregate($count as Count))

Autres fonctions similaires qui n'ont pas été ajoutées à la v4 pour la même raison :

/api/v2/Scans/CountByStatus

/api/v2/Scans/CountByTechnology

/api/V2/Users/Count

/api/v2/Issues/CountBySeverity/{scope}/{scopeId}

/api/v2/Issues/CountByStatus/{scope}/{scopeId}

/api/V2/AssetGroups/Count

Modification des termes pour les technologies d'examen

Les termes utilisés pour les technologies d'examen ont été modifiés dans l'API v4 :
  • DynamicAnalyzer ⇒ Dast
  • StaticAnalyzer ⇒ Sast
  • IASTAnalyzer ⇒ Iast
  • ScaAnalyzer ⇒ Sca

Ces modifications ont affecté les fonctions d'API suivantes dans la section Examens :

  • GET /api/v2/Scans/DynamicAnalyzer/{scanId} ⇒ /api/v4/Scans/Dast/{scanId}
  • GET /api/v2/Scans/StaticAnalyzer/{scanId} ⇒ /api/v4/Scans/Sast/{scanId}
  • GET /api/v2/Scans/ScaAnalyzer/{scanId} ⇒ /api/v4/Scans/Sca/{scanId}
  • GET /api/v2/Scans/StaticAnalyzerExecution/{executionId} ⇒ /api/v4/Scans/SastExecution/{executionId}
  • GET /api/v2/Scans/DynamicAnalyzerExecution/{executionId} ⇒ /api/v4/Scans/DastExecution/{executionId}
  • GET /api/v2/Scans/DynamicAnalyzerScanFile/{executionId} ⇒ /api/v4/Scans/DastScanFile/{executionId}
  • POST /api/v2/Scans/StaticAnalyzer ⇒ /api/v4/Scans/Sast
  • POST /api/v2/Scans/DynamicAnalyzerUploadedResultsFromFile ⇒ /api/v4/Scans/DastScanResults
  • POST /api/v2/Scans/IASTAnalyzer ⇒ /api/v4/Scans/Iast

Pour créer des examens DAST, les trois fonctions de l'API v2 ont été regroupées en une seule fonction qui expose toutes les options. Notez que le modèle requis pour la nouvelle fonction dans la v4 diffère des modèles de la v2. Pour plus d'informations, consultez la documentation d'API.

Les trois fonctions suivantes :

POST /api/v2/Scans/DynamicAnalyzer

POST /api/v2/Scans/DynamicAnalyzerWithFile

POST /api/v2/Scans/DynamicAnalyzerWithFiles

Sont fusionnées en une seule fonction :

POST /api/v4/Scans/Dast

Modification du modèle de problème

Peu de modifications ont été apportées au modèle du problème (renvoyé par GET /api/v4/Issues/{scope}/{scopeId}) :
  • Les types d'«Id » et d'« ApplicationId » sont passés de chaîne à guid. Il s'agit d'un ajustement mineur, mais cela affecte le format des filtres OData.
  • Les propriétés obsolètes suivantes ont été supprimées du modèle : AvailabilityImpact, Classification, ConfidentialityImpact, Authentication, AccessComplexity, AccessVector, ProjectName, Protocol, RemediationLevel, ReportConfidence, NessusPluginId, FixRecommendation, IntegrityImpact, Summary, WhiteHatSecVulnId, StepsToReproduce, Description ,Exploitability, ApplicationName, FriendlyId.