Initier les tâches avec POST
Cette section :
•Syntaxe JSON pour les requêtes POST
•Charger les fichiers avec la requête POST
Envoyer la requête
Une tâche RaptorXML+XBRL Server est initiée avec la méthode POST HTTP
Méthode HTTP | URI | Type de contenu | Corps |
POST | http://localhost:8087/v1/queue/ | application/json | JSON |
Veuillez prendre note des points suivants :
•L'URI ci-dessus a une adresse de serveur qui utilise les paramètres de la configuration initiale.
•L'URI a un chemin /2025.0/queue/, qui doit être présent dans l'URI. Il peut être considéré comme un dossier abstrait dans la mémoire dans laquelle la tâche est placée.
•Le numéro de version correct /vN est celui que le serveur retourne (et pas nécessairement celui dans cette documentation). Le nombre que le serveur retourne est le numéro de version de l'interface HTTP actuelle. Les numéros de version précédents indiquent des versions plus anciennes de l'interface HTTP, qui sont toujours pris en charge pour la rétrocompatibilité.
•L'en-tête doit contenir le champ : Content-Type: application/json. Néanmoins, si vous souhaitez charger des fichiers dans le corps de la requête POST, alors le type de contenu de l'en-tête du message doit être configuré sur multipart/form-data (par ex. Content-Type: multipart/form-data). Voir la section Charger les fichiers avec la requête POST pour plus de détails.
•Le corps de la requête doit être en format JSON.
•Les fichiers à traiter doivent se trouver sur le serveur. Donc les fichiers doivent soit être copiés sur le serveur avant d'effectuer une requête, ou être chargés avec la requête POST. Dans ce cas, le type de contenu de l'en-tête de message doit être configuré sur multipart/form-data. Voir la section Charger les fichiers avec la requête POST ci-dessous pour plus de détails.
Pour vérifier la bonne formation d'un fichier XML, la requête dans le format JSON ressemblerait à l'exemple suivant :
{
"command": "wfxml", "args": [ "file:///c:/Test/Report.xml" ]
}
Les commandes valides, et leurs arguments et options, sont telles que documenté dans la section de Ligne de commande.
Syntaxe JSON pour les requêtes HTTP POST
{ "command": "Command-Name", "options": {"opt1": "opt1-value", "opt2": "opt2-value"}, "args" : ["file:///c:/filename1", "file:///c:/filename2"] }
•Tout le texte noir est fixe et doit être inclus. Cela contient toutes les accolades, double guillemets, virgules, double-point et crochets. L'espace blanc peut être normalisé.
•Les italiques bleus sont des espaces réservés et sont synonymes de noms de commande, options et valeurs d’option et de valeurs d’argument. Veuillez vous référer à la section de ligne de commande pour une description des commandes.
•Les clés command et args sont obligatoires. La clé options est optionnelle. Certaines clés options ont des valeurs par défaut ; donc parmi ces options, seules celles dont les valeurs par défaut doivent être changées doivent être spécifiées.
•Tous les strings doivent être inclus dans des doubles guillemets. Les valeurs booléennes et les nombres n'ont pas de guillemets. Donc : {"error-limit": "unlimited"} et {"error-limit": 1} est l'usage correct.
•Notez que les URI fichier —plutôt que les chemins de fichier—sont recommandés et qu’ils utilisent des barres obliques. Les chemins de fichier Windows, si utilisés, prennent des barres obliques vers l'arrière. De plus, les barres obliques file-path Windows doivent être dans une séquence d’échappement dans JSON (avec des séquences d’échappement de barre oblique ; comme "c:\\dir\\filename"). Veuillez noter que les URI de fichier et les chemins de fichier sont des strings et doivent donc se trouver entre guillemets. |
Voici un exemple avec des options. Veuillez noter que certaines options (comme input ou xslt-version) prennent une valeur d'option directe, alors que d'autres (comme param) prennent une paire de valeur-clé en tant que leur valeur et nécessitent donc une syntaxe différente.
{
"command": "xslt",
"args": [
"file:///C:/Work/Test.xslt"
],
"options": {
"input": "file:///C:/Work/Test.xml",
"xslt-version": "1",
"param": {
"key": "myTestParam",
"value": "SomeParamValue"
},
"output": "file:///C:/temp/out2.xml"
}
}
L'exemple ci-dessous montre un troisième type d'option : celle d'un table de valeurs (comme pour l'option xsd ci-dessous). Dans ce cas, la syntaxe à utiliser est celle d'un tableau JSON.
{
"command": "xsi",
"args": [
"file:///C:/Work/Test.xml"
],
"options": {
"xsd" : ["file:///C:/Work/File1.xsd", "file:///C:/Work/File2.xsd"]
}
}
Charger les fichiers avec la requête POST
Les fichiers à traiter peuvent être téléchargés dans le corps de la requête POST. Dans ce cas, la requête POST doit être effectuée comme suit.
En-tête de requête
Dans l'en-tête de requête, définir Content-Type: multipart/form-data et spécifier tout string arbitraire en tant que la limite. Voici une en-tête d'exemple :
Content-Type: multipart/form-data; boundary=---PartBoundary
L'objectif de la limite est de définir des limites des différentes parties données de forme dans le corps de la requête (voir ci-dessous).
Corps de requête : Partie de message
Le corps de la requête détient les parties données de forme suivantes, séparées par le string de limite spécifié dans l'en-tête de requête (voir ci-dessus) :
•Parties données de forme obligatoires : msg, qui spécifie l’action traitée requise, et args, qui contient les fichiers à télécharger comme argument/s de la commande spécifiée dans la partie form-data msg. Voir la liste ci-dessous.
•Partie données de forme optionnelle : Un nom de partie form-data additional-files, qui contient des fichiers référencés de fichiers dans msg ou des parties form-dataargs. Des parties de données de forme supplémentaires nommées selon une option de la commande peut aussi contenir des fichiers à charger.
Note : tous les fichiers chargés sont créés dans un seul répertoire virtuel.
Voir Exemple-1 (avec des légendes) : Valider XML pour une explication détaillée du code, et Exemple-2 : Utiliser un catalogue pour trouver le schéma.
Tester avec CURLVous pouvez utiliser une application de transfert de données tiers comme CURL (http://curl.haxx.se/) pour tester la requête POST. CURL propose une option de trace précieuse qui génère et liste les limites des parties des requêtes. Cela vous épargnera la tâche de créer manuellement les limites de partie. La section Tester avec CURL décrit comment utiliser CURL .
|
Charger des archives ZIP
Des archives ZIP peuvent aussi être chargés et des fichiers se trouvant dans un ZIP peuvent être référencés en utilisant le schéma additional-files. Par exemple :
additional-files:///mybigarchive.zip%7Czip/biginstance.xml
| Note : | La partie |zip/ doit être échappée par URI en tant que %7Czip/ pour pouvoir se conformer à l'URI RFC puisque le symbole | n'est pas directement autorisé. L'utilisation de motifs glob (* et ?) est aussi autorisée. Vous pouvez donc utiliser quelque chose comme cela pour valider tous les fichiers XML dans l'archive ZIP : {"command": "xsi", "args": ["additional-files:///mybigarchive.zip%7Czip/*.xml"], "options": {...}} |
Voir Exemple-3: Utiliser les archives ZIP pour une liste du code d'exemple.