@malcolmsparks: i'm trying to use a conditional schema on a get parameter, but that (obviously) doesn't work well with the swagger description

>>> don't know how to create json-type of: [email protected]

is that even possible to support?

{(s/optional-key :tag)      (s/conditional vector? [String] :else String)}

you know, it's to support various clients using all different solutions for an array of parameters

?tag=bla > parse to single String

?tag=foo&tag=bar > parse to vector of Strings

?tag=[foo,bar] > parse to vector of Strings

in this case use s/Any

and do your own parsing

@stijn, the schema that is supported is the same as ring-swagger - https://github.com/metosin/ring-swagger

the problem is there is only an approximate mapping between Prismatic Schema and JSON Schema (that Swagger needs)

I see

parameter declaration is useful in the common simple cases, where you know upfront what your parameter is, etc. and that's when it's useful in Swagger. It sounds like your case is complex, and you need to bypass the built-in mechanisms and provide your own validation code - thankfully in clojure that's straight-forward, in many other systems it isn't

absolutely, the existing api has the parsing code

I was just wondering if this would be possible

the rule-of-thumb is if you know you parameters in full at declaration-time (static), rather than at request-time (dynamic), then it's something you can publish in the swagger spec. The swagger spec should be a static document you can publish, it shouldn't be dependent on the incoming request, otherwise it's a bit pointless - the need it serves is to tell downstream developers how to call your service (before they actually call it)

default values for optional keys would also be nice, but as I understand from https://groups.google.com/forum/#!topic/prismatic-plumbing/NWUnqbYhfac that would require a custom schema and the coercion to take this into account

and an update to ring-swagger I guess, if you want to indicate this in the swagger.json (which supports default values)

have you tried {(s/optional-key :foo} "bar"} ?

oh sorry, @stijn, you're asking for something different

yeah, ok, optional key default values would be nice - I'll think about it

(s/enum "foo" "bar") with "foo" being the default

that feels complected

what about a map you can pre-merge with the final parameters map?

(merge defaults parameters)

better!

the trouble is the parameter map already contains keys for methods and parameter types, it will soon get ugly, need to think this one through

ok

I can't get this to work:

{(s/optional-key "tag[]")  String}

I get a 400 with ?tag[]=something

how about (with-default "foo" (s/enum "foo" "bar"))

yes indeed

i think tag[] is a php thing

there is support for multi-parameters but not yet released (it's on master)

I know, but we have an iOS library that uses this

you do this : {(s/optional-key "tag") [String]}

@stjin, ok - where the stack trace coming from? something I can fix in yada?

sorry, gotta rush!

no problem see you later

should I see a trace on a 400? my options have

:error-handler identity

@stijn, at this stage of yada's development, it's a good idea to clone it in your Leiningen checkouts/ dir and be able to put in printlns to help debug

it is maturing, and is mostly feature complete, but needs quite a lot more polish before I can release a stable 1.0

ok, off to another meeting!

ok, will do that

@malcolmsparks: i'm seeing a 202 response with no body from a PUT request

that seems like it's intentional - https://github.com/juxt/yada/blob/master/src/yada/methods.clj#L206

what's the rationale behind not returning a body ?

ah, RTFM - will "Prefer: return=representation" be supported at some point ?

no biggie, i can use POST for now