(defmethod shape-to-spec “list” [ns [name {{:strs [shape]} “member” :strs [max]}]]
  `(spec/and
     (spec/coll-of ~(keyword ns (aws/dashed shape)) :max-count ~max)
     (spec/conformer identity #(if (sequential? %) % [%])))) ; HAL ❤

this conformer is a case of protocol leak

HAL allows to replace single-item lists by just the item

of course you see that it’s in the “unform” direction

conform is from edn to payload and unform from payload to edn

I’d like to get rid of all conforms because I want specs to work first as a clean documentation.

I don’t want to muddy this with protocol details

so in gen-api I make provision for some vars (prefixed by ser- deser- req- and resp- followed by a spec name), they are expectd to be populated by functions doing transformations.

right

obviously these fns would be protocol-dependent

so for example for rest-xml, xml would be serialed/deserialized with these fns

maybe not entirely

the core fn would be rest-xml-call, it could do the generic xml lifting

req- resp- could work from the request/respoinse maps with parsed bodies

and ser- deser- do the local transformations

example of local transformation: turning a <list> tag into an actual list

ah, true

so while making a call, the data that is fed to say ser-create-function-request would be checked against a spec?

Yes 1/ call conform or valid 2/ call req<-create-function-request -- it indirectly calls some ser-stuff to performs coercion and small fixes 3/ serialize the body of the request in the *-call fn

thinking about pagination

at least one can grab token from response and use it for next request

hey, @cgrand I am going to look at your wip next monday

did not have the time last few days

hmm master...

I think I've formed some obstacles in form of merge conflicts if thinking of rebasing the wip