Initier les tâches avec POST

www.altova.com Imprimer cette rubrique Page précédente Un niveau supérieur Page suivante

Accueil >  API serveur : REST HTTP, COM/.NET, Java > Interface Client HTTP > Requêtes Client >

Initier les tâches avec POST

Cette section :

 

Envoyer la requête
Syntaxe JSON pour les requêtes POST
Charger les fichiers avec la requête POST
Charger des archives ZIP

 

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 noter les 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 /v1/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 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é.
Le texte en italique bleu sont des espaces réservés et représente les noms de commande, les options et valeurs d'option et les 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 ceux 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.

 

Veuillez noter que les URI (et non pas les chemins de fichier) sont recommandés et qu'ils utilisent des barres obliques vers l'avant. Les chemins de fichier Windows, si utilisés, prennent des barres obliques vers l'arrière. De plus, les barres obliques vers l'arrière de chemin de fichier de Windows doivent être échappées dans JSON (avec des échappements de barres obliques vers l'arrière : "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 la requête : partie 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 de traitement requise, et args, qui contient les fichiers à charger en tant que l'argument de la commande spécifiée dans la partie de donnée de forme msg. Voir la liste ci-dessous.
Partie données de forme optionnelle : un nom additional-files de données de forme additional-files, qui contient les fichiers référencés depuis les fichiers dans les parties de données de forme msg ou args. 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 CURL

 

Vous 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 scheme additional-files. Par exemple :

 

additional-files:///mybigarchive.zip%7Czip/biginstance.xml

 

 

Note :La partie |zip/ doit être échappée avec un URI comme %7Czip/ pour pouvoir se conformer à l'URI RFC puisque le symbole | n'est pas autorisé directement. L'utilisation des motifs glob (* et ?) est aussi autorisée. Donc vous pouvez utiliser quelque chose du genre suivant 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.

 


© 2019 Altova GmbH