Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Multiple type Options within Response Models #165

Open
GuyPaddock opened this issue Aug 7, 2019 · 0 comments · May be fixed by #168
Open

Support for Multiple type Options within Response Models #165

GuyPaddock opened this issue Aug 7, 2019 · 0 comments · May be fixed by #168

Comments

@GuyPaddock
Copy link

We are writing a client to wrap a vendor-supplied REST API. One of the values that the API returns can be either null, a scalar string value, or an array of strings. I'm trying to model this as follows:

models:
  AssetMetadataResponse:
    type: 'object'
    location: 'json'
    properties:
      data:
        type: 'array'
        required: true
        items:
          type: 'object'
          properties:
            attribute_id:
              type: 'integer'
              required: true
              minimum: 1
            value:
              type:
                # FIXME: Guzzle does not handle this correctly
                - 'null'
                - 'string'
                - 'array'
              items:
                type: 'string'

This causes problems, because it appears that \GuzzleHttp\Command\Guzzle\ResponseLocation\JsonLocation::recurse does not handle the case where type is an array of types rather than a single type. This causes arrays of values to come through as empty arrays.

I'd love it if Guzzle Services was able to support responses that have fields that can vary in type. Even better would be if Guzzle Services had a construct like JSON Schema's oneOf, where I can model each permutation of the data fields separately.

GuyPaddock pushed a commit to GuyPaddock/guzzle-services that referenced this issue Aug 13, 2019
This allows fields within a response model to vary within a set of
allowed types instead of being required to be a specific JSON schema
value type.

This also corrects detection of null response values. It also fixes
detection of associative vs. indexed arrays so that the order in which
the type definitions appear in the service description doesn't affect
which type gets returned when a field can be either an object or an
array.

Closes guzzle#165.
GuyPaddock pushed a commit to GuyPaddock/guzzle-services that referenced this issue Aug 13, 2019
This allows fields within a response model to vary within a set of
allowed types instead of being required to be a specific JSON schema
value type.

This also corrects detection of null response values. It also fixes
detection of associative vs. indexed arrays so that the order in which
the type definitions appear in the service description doesn't affect
which type gets returned when a field can be either an object or an
array.

Closes guzzle#165.
@GuyPaddock GuyPaddock linked a pull request Aug 13, 2019 that will close this issue
GuyPaddock pushed a commit to GuyPaddock/guzzle-services that referenced this issue Aug 13, 2019
This allows fields within a response model to vary within a set of
allowed types instead of being required to be a specific JSON schema
value type.

This also corrects detection of null response values. It also fixes
detection of associative vs. indexed arrays so that the order in which
the type definitions appear in the service description doesn't affect
which type gets returned when a field can be either an object or an
array.

Closes guzzle#165.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant