2017-02-17 2 views
4

Je cherche une façon élégante de définir une API capable de consommer des données JSON ainsi que des données de formulaire. L'extrait suivant fonctionne, mais il n'est pas élégant et nécessite tout type de code moche dans le backend. Y a-t-il une meilleure façon de le définir?Écrire un document swagger qui consomme plusieurs types de contenu, par ex. application/json ET application/x-www-form-urlencoded (sans duplication)

Ce qui fonctionne en ce moment:

paths: 
    /pets: 
    post: 
     consumes: 
     - application/x-www-form-urlencoded 
     - application/json 
     parameters: 
     - name: nameFormData 
     in: formData 
     description: Updated name of the pet 
     required: false 
     type: string 
     - name: nameJSON 
     in: body 
     description: Updated name of the pet 
     required: false 
     type: string 

idée de base de la façon dont je voudrais que cela fonctionne:

paths: 
    /pets: 
    post: 
     consumes: 
     - application/x-www-form-urlencoded 
     - application/json 
     parameters: 
     - name: name 
     in: 
     - formData 
     - body 
     description: Updated name of the pet 
     required: true 
     type: string 

Mais cela ne fonctionne pas parce que la valeur doit in être une chaîne, pas un tableau.

Des bonnes idées?

+0

C'est un vrai problème, espérons qu'il y a une solution, sinon vous pourriez ouvrir un problème sur le ir github. –

+0

Egalement intéressé par faire la même chose, bien que dans mon cas spécifiquement je voudrais donner aux utilisateurs la possibilité de télécharger une image dans JSON/Base64 s'ils le choisissent – Matt

Répondre

3

Dans OpenAPI 2.0, il n'y a aucun moyen de décrire cela. Les paramètres de forme et de corps s'excluent mutuellement, de sorte qu'une opération peut avoir des données de formulaire OU un corps JSON, mais pas les deux. Une solution de contournement possible consiste à avoir deux points de terminaison distincts - un pour les données de formulaire et un autre pour JSON - si cela est acceptable dans votre scénario. Cela dit, cela sera possible dans OpenAPI 3.0 (qui est RC au moment de l'écriture). 3.0 introduit le mot-clé requestBody qui est utilisé pour définir les types de contenu possibles, de sorte que nous pourrons avoir application/json et application/x-www-form-urlencoded en une seule opération. Différents types de contenu peuvent avoir le même schéma ou des schémas différents.

Lorsque 3.0 est sorti et l'outillage est mis à jour, votre exemple peut être décrit comme suit:

paths: 
    /pets: 
    post: 
     requestBody: 
     required: true 
     content: 

      application/json: 
      schema: 
       $ref: '#/components/schemas/Pet' 

      application/x-www-form-urlencoded: 
      schema: 
       $ref: '#/components/schemas/Pet' 

     responses: 
     '200': 
      description: OK 

components: 
    schemas: 
    Pet: 
     type: object 
     properties: 
     name: 
      type: string 
      description: Updated name of the pet 
     required: 
     - name 

Plus d'info: