Guys, hi, we're having problems route matching paths with spaces (a requirement of the project), from yada/swaggered resources Something like

["/content" 
       [[["/" :path1 "/" :path2 "/" :path3] :handler]]
]

Thanks @naartjie - it's mostly likely the path processing code in yada.swagger. @imre and I are reviewing the path encoding in bidi too.

@malcolmsparks @imre: great, would you like me to open an issue with a minimal repro?

Yes please @naartjie

From https://yada.juxt.pro/manual/130_swagger.md: > The swaggered function can be used to further wrap the route structure. > This function takes 2 arguments. The first argument is a 'base template' map which contains all the static data that should appear in the spec. such as the Swagger service meta-data. The second argument is simply the bidi routing tree containing your yada resources.

The documentation seems to have the parameters backwards.

Should I report documentation issues on the Github repo yet?

Defining my resource hierarchy with this:

(def api ["/hello-swagger" (yada/swaggered ["/hello" hello] {:info {:title "Hello world" :version "1.0" :description "Stuff"} :basePath "/hello-swagger"})])

GET /hello appears under a heading titled “default” and there’s no description of GET /hello, how would I add this metadata via yada?

I guess I also don’t understand what is being described as “default”. See here: https://yada.juxt.pro/manual/images/greetings-swagger.png

@jonathanj: You can use tags to divide your api into sections with a better description. And to to get descriptions on GET /hello you need to add a description and/or summary to the resource hello.

(yada/swaggered [“/hello” (yada/resource {:methods {:get {:swagger/tags [“getters”], :summary “Mighty GET”, :response (constantly “Test”)}}})], {:info “Awesome API”, :tags [{:name “getters”, :description “All the best methods”}]})

@griff: Ah, great, thank you! Is there documentation around this that I can read somewhere?

So now my hello resource is defined as:

(def hello (yada/resource {:methods {:get {:swagger/tags ["getters"] :response "Hello world!" :description "Here I am"}}}))

I guess I’m missing a :produces key for my method, certainly adding one fixes the problem.

@jonathanj: Yah that might be it. I did my example from memory

Why do I have to specify that though?

Or rather, what happens when one does (yada “Hello World!”) that they don’t have to specify that?

It has a :produces “text/plain"

(extend-protocol ResourceCoercion
  String
  (as-resource [s]
    (resource
     {:properties {:last-modified (to-date (now))
                   :version s}
      :methods
      {:get
       {:produces
        [{ ;; Without attempting to actually parse it (which isn't
           ;; completely impossible) we're not able to guess the
           ;; media-type of this string, so we return text/plain.
          :media-type "text/plain"
          :charset charset/platform-charsets}]
        :response (fn [ctx] s)}}})))

Hmm, so I guess (yada/resource) produces a resource without going via the coercion.

Yes yada/resource makes a resource directly

It would be convenient if the :produces value could be inferred from the :response but I guess that’s not really that easy and you also need to know that information upfront so it can go in swagger.json.

But the beauty of yada is that you can do: (assoc-in (yada “Hello World”) [:resource :methods :get :summary] “My awesome summary”)

And you need produces because content negotiation happens before response is called

Yeah, good point about it just being a data structure.

Thank you, @griff.