ring-swagger

ring-swagger & compojure-api
logistark 2018-02-19T12:20:54.000393Z

Hello, i have a problem with Compojure-Api it seems that is not generating valid Swagger 2 specs. Why compojure-api generate oneOf tags when is not in the spec of swagger 2?

borkdude 2018-02-19T14:24:28.000025Z

What is the spec for a formData parameter name. I want to use foo/bar, but the UI truncates it to bar only when I use :foo/bar in the Schema spec

borkdude 2018-02-19T14:29:29.000282Z

Using a string instead of a keyword works

slipset 2018-02-19T21:22:48.000243Z

I might be using stuff wrongly, but I get an assertion-error when using spec-coercions with compojure-api.

slipset 2018-02-19T21:22:55.000210Z

The offending function is

slipset 2018-02-19T21:22:58.000244Z

(defn nested-key [n k]
#_    (assert (qualified-keyword? n) (str  "spec must have a qualified name" n))
    (keyword (str (namespace n) "$" (name n)
                  (if-let [kns (namespace k)]
                           (str "$" kns)) "/" (name k))))

slipset 2018-02-19T21:23:20.000102Z

in 'spec-tools.data-spec)

slipset 2018-02-19T21:24:19.000283Z

The offending line (which is commented out over) was added in https://github.com/metosin/spec-tools/commit/1a8dd077c254563367be5ec2ca9b40a561b59421#diff-a7972339bb0aba07594a0747da1a3c12

slipset 2018-02-19T21:25:04.000252Z

If there is any interest, I can dig deeper and try to figure out a minimal example to reproduce this.

slipset 2018-02-19T21:37:54.000351Z

Oh, and a bonus question:

slipset 2018-02-19T21:38:33.000089Z

I'm working on the backend-team, using spec, so we're quite happy writing out specs and maps with lisp-case keys, as

slipset 2018-02-19T21:38:46.000175Z

{:foo-bar-baz "qix"}

slipset 2018-02-19T21:39:57.000340Z

Now, our frontend team are not too fond of lisp-case, so before sending this off to the frontend, we camelCase it, as such

slipset 2018-02-19T21:40:09.000086Z

{:fooBarBaz "qix"}

slipset 2018-02-19T21:41:24.000301Z

So when using compojure-api with spec-coercion, the swagger docs say that we're returning {"foo-bar-baz": "qix}, when in reality we return {"fooBarBaz" : "qix"}.

slipset 2018-02-19T21:41:46.000316Z

Any thoughts on how to make the swagger docs reflect our reality?

ikitommi 2018-02-19T21:44:00.000267Z

the first one, I’m 99% sure that the SpecCoercion uses gensym to generate names for the anonymous specs, and after the change, keyword is required.

ikitommi 2018-02-19T21:44:22.000216Z

something like:

(defn- ensure-name [?name]
   (or ?name (keyword "" (name (gensym "spec")))))
should help.

ikitommi 2018-02-19T21:47:44.000142Z

the second, I don’t think there is easy way. But you can do it by modifying the response from the swagger-docs endpoint… if you remove the swagger definitions from the api and mound swagger-docs manually, you can wrap the docs with a custom middleware that transforms the models with walk etc.

slipset 2018-02-19T21:50:16.000200Z

Re the second, I was thinking that it would be a possibility to do the walk thingy.