To keep specs cleaner and to serve documentation better. Partial work in a wip branch currently.
Making note of Slack discussion:
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.
the core fn would be rest-xml-call, it could do the generic xml lifting
req-resp- could work from the request/response maps with parsed bodies
and ser-deser- do the local transformations
example of local transformation: turning a <list> tag into an actual list
reqserrespdeser are not specs but functions, and they are not generated at the moment. Vars are created beforehand to be declared (because cycles may happen).
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
To keep specs cleaner and to serve documentation better. Partial work in a
wipbranch currently.Making note of Slack discussion:
So in
gen-apiI make provision for some vars (prefixed byser-deser-req-andresp-followed by a spec name), they are expectd to be populated by functions doing transformations.the core fn would be
rest-xml-call, it could do the generic xml liftingreq-resp-could work from the request/response maps with parsed bodiesand
ser-deser-do the local transformationsexample of local transformation: turning a
<list>tag into an actual listreqserrespdeserare not specs but functions, and they are not generated at the moment. Vars are created beforehand to be declared (because cycles may happen).1/ call conform or valid 2/ call
req<-create-function-request-- it indirectly calls someser-stuffto performs coercion and small fixes 3/ serialize the body of the request in the*-callfn