Skip to content

Feature Request - Ability to Bind Parameter Filters to Specific Request Stages #169

@GuyPaddock

Description

@GuyPaddock

As touched on briefly in #134, if a parameter has a filter defined, Guzzle Services applies that filter at the following stages:

  1. Before validation, in \GuzzleHttp\Command\Guzzle\Handler\ValidatedDescriptionHandler::__invoke().
  2. Before writing the value out to the wire in a request, in:
    a. GuzzleHttp\Command\Guzzle\RequestLocation\AbstractLocation::prepareValue()
    b. GuzzleHttp\Command\Guzzle\RequestLocation\AbstractLocation::resolveRecursively()
    c. GuzzleHttp\Command\Guzzle\Serializer
    d. ...and several different request location handlers.
  3. After reading a value in from a response on the wire, in several response location handlers.

This leads to the following awkwardness:

  • If a filter like json_encode() is being used to control the way a parameter is being written-out to the wire:
    • It inadvertently has an effect on the format of the parameter on its way through validation. So, for example, a value that should come in as an array has to be declared as a string to prevent validation from erroring-out on the JSON string. There's no way to make these types of filters happen only after validation.
    • It gets applied twice (in both 1 and 2 above), so instead of sending a JSON string, it sends a JSON-escaped JSON string (i.e. the value gets double-encoded, as a quoted JavaScript string instead of JSON).
  • Default values only run through one filter (2), which leads to different results than if you passed-in a value equal to the default. IMHO, the default value should be run through validation the same way as passed-in values, but that's a separate issue.
  • Filter functions/methods don't really have a good way to differentiate between filtering that happens to values going out in a request and values coming in from a response. This is likely not a huge issue since different parameters are used for request and response data, AFAIK.

Ideally, there'd be a way to "bind" a filter to a particular stage of the process, so that it's only invoked when desired.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions