Fork me on GitHub
#yada
<
2015-10-08
>
stijn08:10:53

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

stijn08:10:58

>>> don't know how to create json-type of: schema.core.ConditionalSchema@30d4132a

stijn08:10:35

is that even possible to support?

stijn08:10:57

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

stijn08:10:54

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

stijn08:10:14

?tag=bla > parse to single String

stijn08:10:35

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

stijn08:10:49

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

malcolmsparks09:10:49

in this case use s/Any

malcolmsparks09:10:55

and do your own parsing

malcolmsparks09:10:22

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

malcolmsparks09:10:51

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

malcolmsparks09:10:10

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

stijn09:10:18

absolutely, the existing api has the parsing code

stijn09:10:39

I was just wondering if this would be possible

malcolmsparks09:10:48

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)

stijn09:10:17

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

stijn09:10:02

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

malcolmsparks09:10:31

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

malcolmsparks09:10:56

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

malcolmsparks09:10:14

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

stijn09:10:27

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

malcolmsparks09:10:09

that feels complected

malcolmsparks09:10:31

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

malcolmsparks09:10:35

(merge defaults parameters)

malcolmsparks09:10:10

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

stijn09:10:42

I can't get this to work:

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

stijn09:10:00

I get a 400 with ?tag[]=something

malcolmsparks09:10:09

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

stijn09:10:26

yes indeed

malcolmsparks09:10:29

i think tag[] is a php thing

malcolmsparks09:10:43

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

stijn09:10:49

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

malcolmsparks09:10:00

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

malcolmsparks09:10:27

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

malcolmsparks09:10:32

sorry, gotta rush!

stijn09:10:40

no problem see you later

stijn09:10:48

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

:error-handler identity

malcolmsparks12:10:14

@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

malcolmsparks12:10:36

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

malcolmsparks12:10:52

ok, off to another meeting!

stijn12:10:53

ok, will do that

mccraigmccraig12:10:00

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

mccraigmccraig12:10:16

what's the rationale behind not returning a body ?

mccraigmccraig12:10:16

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

mccraigmccraig12:10:54

no biggie, i can use POST for now