Open ugexe opened 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:
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 complaintraw-query-hash
and similar to provide access to the original data, for if anyone wants to recover thatThe 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?
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? ).