Please do not post any internal, closed source snippets on this public issue tracker!
Purpose
One of our users have asked for us to support arrays in their query params, as it is needed to support queries passed to one of their downstream systems.
This means they require both support for both server and client code which handles array query parameters
e.g A call is made tobff/customers?1,2,3,4 which must be passed on to downstream/customers?1,2,3,4
Currently, this produces the following sysl from the importer
##########################################
## ##
## AUTOGENERATED CODE -- DO NOT EDIT! ##
## ##
##########################################
testArray "Simple":
@description =:
| No description.
/test:
GET ?key={key}:
| No description.
return ok
#---------------------------------------------------------------------------
# definitions
!alias key:
sequence of string
Suggested approaches
What have you tried, and how might this problem be solved?
This means that Sysl needs to represent information regarding how the parameter should be serialised/ deserialised, as well as whether the parameter should be exploded.
A full implementation would include full support of the various ways of serialising parameters listed in the link below
Basic support would just involve parsing the parameter when an array type is specified, assuming the string separator is used
This is the default assumption made for OpenAPI3 specs and should apply generally to Sysl and be documented
Please do not post any internal, closed source snippets on this public issue tracker!
Purpose
One of our users have asked for us to support arrays in their query params, as it is needed to support queries passed to one of their downstream systems.
This means they require both support for both server and client code which handles array query parameters
e.g A call is made to
bff/customers?1,2,3,4
which must be passed on todownstream/customers?1,2,3,4
Example OpenAPI3 spec file
Currently, this produces the following sysl from the importer
Suggested approaches
This means that Sysl needs to represent information regarding how the parameter should be serialised/ deserialised, as well as whether the parameter should be exploded.
A full implementation would include full support of the various ways of serialising parameters listed in the link below
The use of a URL template library would be a recommended approach https://github.com/jtacoma/uritemplates
Taken from https://swagger.io/docs/specification/serialization/#uri-templates
Basic support would just involve parsing the parameter when an array type is specified, assuming the string separator is used This is the default assumption made for OpenAPI3 specs and should apply generally to Sysl and be documented
Basic Support
Full Support
style
andexplode
keywords in query parameters