croservices / openapi-model

Parse and generate OpenAPI v3 documents
Artistic License 2.0
2 stars 1 forks source link

How to implement `styles` for parameters in the overall stack? #5

Open ugexe opened 6 years ago

ugexe commented 6 years ago

Any pointers on how to implement e.g. styles in the overall stack? For instance I expect something would need to validate the uri ( OpenAPI::Schema::Validate? ) and also something to normalize the parameters into what cro passes the request handler ( OpenAPI::Model? Cro::OpenAPI::RoutesFromDefinition? both? ).

jnthn commented 6 years ago

Sorry, I somehow missed this when it was first posted. :-( Yes, this is a somewhat tricky case.

I think OpenAPI::Model perhaps doesn't have much of a role to play in this, aside from providing the values of the style and explode properties, which it already seems to be doing. (However, I'll come back to this in a bit.)

Presumably we'd like to only need to parse the styled input once, and be able to use that for both validation and provide it to the API implementation. The validation wants it readily parsed, since the validation is against the parsed form, not against the input form, as this example from the spec shows:

name: token
in: header
description: token to be passed as a header
required: true
schema:
  type: array
  items:
    type: integer
    format: int64
style: simple

Thus I think the work needs to happen as part of Cro::OpenAPI::RoutesFromDefinition. Another interesting question is if I was implementing the API specified above, and I wrote:

operation 'blah', -> :$name is header {
    ...
}

Then would I get the original header value, or would I get an array of integers? Probably the latter is far more useful. therefore, we could potentially:

  1. Do the parsing in a request processing middleware for operations that need it
  2. Have this middleware mix in a role to request that provides access to the parsed forms. If we're lucky, we'll be able to override methods like query-hash, and everything else in validation and the operation signature binding would just end up working on the parsed data without complaint
  3. Also provide in the role some raw-query-hash and similar to provide access to the original data, for if anyone wants to recover that

The question is to what degree the rest of Cro will be happy with step 2. My gut feeling is that it probably will be for the most part, though the best way is probably to try it.

It's possible that we want to put the parsing of the styles themselves somewhere other than Cro::OpenAPI::RoutesFromDefinition, to allow them to be more widely re-used. I'm not quite sure they fit naturally in OpenAPI::Model, so perhaps some OpenAPI::Styles distribution is in order, which can both parse and serialize each of the styles. (I'm quite keen on building an OpenAPI client too, thus my interesting in the serialization side of things.)

Does this sound like an overall reasonable approach?