How to handle choice in Swagger 2.0

[Nandigam Anil]

"NetworkResource": {
            "description": "SIM, mobile number, or IMEI used by the customer to gain access to services.",
            "type": "object",
            "properties": {
                "imei": {
                    "maxLength": 15,
                    "minLength": 15,
                    "type": "string",
                    "pattern": "[0-9]{15}"
                },
                "sim": {
                    "$ref": "#/definitions/SIM"
                },
                "mobileNumber": {
                    "$ref": "#/definitions/MobileNumber"
                },
                "resourceStatus": {
                    "type": "array",
                    "items": {
                        "$ref": "#/definitions/ResourceStatus"
                    }
                }
            }
        }

In the above Object I need to handle choice bit ween "mobileNumber" , "sim".
How we will represent in swagger 2.0. Can you please help on this.

[Ron]

Hi there,

Apologies for the delayed reply.

If you're looking to describe that you can have one or the other but not both, that's something that can't be done. You also can't specify that at least one of the two needs to be available (a conditional requirement).
You can use inheritance to say that one model has a sim and the other a mobile number, but in order to do that you need an additional field to differentiate the two objects which you do not seem to have.

[Guillermo Martínez del Camino]

I am rescuing this topic as I believe adding choice would be great for the swagger spec. We have got, for instance, an IP that queries billing events. Such events could be calls, SMSs, data traffic, or digital assets such as a movie download. They have a common part (the ID, time, etc.) and a specific part depending on the event type. We are having trouble documenting it as Swagger today cannot cope with the requirement. My proposal would be to add it this way:

"properties": [{

    ...

    "element": {

        "type": "choice",

        "choices": [{

            "$ref": "#/definitions/possibleType1"

        },

        {

            "$ref": "#/definitions/possibleType2"

        },

        {

            "type": "string"

        }]

    }

...

}]

Same way an array has its "items" field or a string has its "enum" or format field, choice would have an array of possible choices which would contain either a type or a reference.

[Ron Ratovsky]

The next version of the spec (not released yet) already has support for this.

--
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.

[Guillermo Martínez del Camino]

That's great news!

[rkushnir]

Hi, when should the next version be released? Do you know already?

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggersocket+unsub...@googlegroups.com.

[tony tam]

Sometime in the new year.  Please follow https://twitter.com/OpenApiSpec for notifications on it.

To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggers...@googlegroups.com.

[Pedro Maia]

oneOf  (inoneOf, anyOf, allOf, not) SPEC see https://swagger.io/docs/specification/data-models/oneof-anyof-allof-not/