Swagger UI - null for verb valuem or malformed JSON, gives CORS message, enum overrides value

[Gregg Irwin]

Hi there. I'm new to Swagger, and converting existing API specs from another format to Swagger JSON (programatically).

1) https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#path-item-object says all the fixed fields (HTTP verbs) are Operation Object types, so my prototype object had them as null values. When you do that, the swagger UI hangs with the "Can't read from server. It may not have the appropriate access-control-origin settings." result, or "fetching resource list: ..." depending on other contents in the file. If they are empty strings, it's happy. Oh, and I also get the CORS message if the JSON is malformed in any way. 

2) If I have a parameter with an enum field in it, no matter the value, the UI doesn't show the normal value field. Enum seems to override it. Which means I can't include it in a parameter prototype.

My question is: What are best practices for formatting Swagger JSON? Should I be able to safely include all fields, or do I need to custom emit objects, omitting anything not used? The two issues above seem like bugs to me, but I thought I'd ask.

Cheers.

[Ron Ratovsky]

Hi Gregg,

Happy to hear you're moving to Swagger.

1) The bug here is that the error reported is not the right now. It is, however, not permitted to have 'null' values for operations. If you don't have an operation described for a given verb, omit it.

2) Not sure I follow your question here. If you can provide a sample, that may be easier.

--
You received this message because you are subscribed to the Google Groups "Swagger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-----------------------------------------

http://swagger.io
https://twitter.com/SwaggerApi
-----------------------------------------

[Gregg Irwin]

Thanks Ron!

1) The bug here is that the error reported is not the right now. It is, however, not permitted to have 'null' values for operations. If you don't have an operation described for a given verb, omit it.

OK. If you tally votes on this, +1 me for allowing nulls. And +2 me for adding a note about this to the docs.

 

2) Not sure I follow your question here. If you can provide a sample, that may be easier.

Sure. petstore demo has this under /pet/pos/:

                "parameters": [

                    {

                        "in": "body",

                        "name": "body",

                        "description": "Pet object that needs to be added to the store",

                        "required": true,

                        "schema": {"$ref": "#\/definitions\/Pet"}

                    }

                ],

Just add enum to that param. i.e.:

                "parameters": [

                    {

                        "in": "body",

                        "name": "body",

                        "description": "Pet object that needs to be added to the store",

                        "required": true,

                        "schema": {"$ref": "#\/definitions\/Pet"},

                        "enum": []

                    }

                ],

And see what happens in the UI.

[Ron Ratovsky]

1) I don't. :) No reason to allow nulls. And the docs don't state it's allowed, so it isn't. null is not not the same as omitting.

2) That specific example is probably not what you had in mind, because you can't have an 'enum' for a 'body' parameter by definition (at least, not in that way).

--

You received this message because you are subscribed to the Google Groups "Swagger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gregg Irwin]

1) I don't. :) No reason to allow nulls. And the docs don't state it's allowed, so it isn't. null is not not the same as omitting.

My misinterpretation of what "Fixed Fields" means in the spec then.

 2) That specific example is probably not what you had in mind, because you can't have an 'enum' for a 'body' parameter by definition (at least, not in that way).

So I have to bake enum into the object only if I have enum values, omitting it otherwise, and pick, say, "query" as the type. i.e., enum CANNOT be applied with a body param, correct?

[Ron Ratovsky]

On Mon, Jun 8, 2015 at 6:15 PM, Gregg Irwin <gr...@pointillistic.com> wrote:

1) I don't. :) No reason to allow nulls. And the docs don't state it's allowed, so it isn't. null is not not the same as omitting.

My misinterpretation of what "Fixed Fields" means in the spec then.

That's a fair input. It means that the names of the fields are fixed, unlike the patterned fields which allow you to name then based on a predefined pattern.

 

 2) That specific example is probably not what you had in mind, because you can't have an 'enum' for a 'body' parameter by definition (at least, not in that way).

So I have to bake enum into the object only if I have enum values, omitting it otherwise, and pick, say, "query" as the type. i.e., enum CANNOT be applied with a body param, correct?

enum can be applied to a body parameter, but it has to be defined in the schema property. It is included in the Schema Object Object.