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

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

Open
ugexe opened this issue May 3, 2018 · 1 comment
Open

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

ugexe opened this issue May 3, 2018 · 1 comment
Labels
question Further information is requested

Comments

@ugexe
Copy link
Collaborator

ugexe commented May 3, 2018

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

@ugexe ugexe added the question Further information is requested label May 3, 2018
@jnthn
Copy link
Member

jnthn commented Jun 19, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants