Fork me on GitHub
#yada
<
2016-06-11
>
naartjie08:06:48

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]]
]
Doesn't like when any of the :path_ parts contain spaces (or %20 urlencoded). I also tried using regex like [#".+" :path1] but that didn't seem to work either. The workaround was to put the resource outside of yada/swaggered for now, with a ["/content/" [[true :handler]]]

malcolmsparks12:06:15

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

naartjie12:06:24

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

jonathanj14:06:56

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.

jonathanj14:06:17

The documentation seems to have the parameters backwards.

jonathanj14:06:37

Should I report documentation issues on the Github repo yet?

jonathanj19:06:58

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"})])

jonathanj19:06:48

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

jonathanj20:06:29

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

griff22:06:13

@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”}]})

jonathanj22:06:51

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

jonathanj22:06:08

So now my hello resource is defined as:

(def hello (yada/resource {:methods {:get {:swagger/tags ["getters"] :response "Hello world!" :description "Here I am"}}}))
but when I try to GET it I get a 406 Not Acceptable

jonathanj22:06:31

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

griff22:06:22

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

jonathanj22:06:57

Why do I have to specify that though?

jonathanj22:06:12

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

griff22:06:58

It has a :produces “text/plain"

griff22:06:46

(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)}}})))

jonathanj22:06:30

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

griff22:06:20

Yes yada/resource makes a resource directly

jonathanj22:06:41

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.

griff22:06:21

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

griff22:06:15

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

jonathanj23:06:27

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