I'm wondering if there is a bit of irregularity in the encoding of parameters. Everything is grouped under :parmeters, such as {:parameters {:body, {:parameters :path, {:parameters :query, except the & parameters to the ? query, which ends up in :params and {:query-params, i.e., for

:parameters {:query {:id "2020"}},
 :params {"id" "2020",
          "limit" "25",
          "page" "0"},

notice that the id appears in both :parmeters :query, and :params, however in :parameters :query, whatever coercion has to be applied, has been applied (but not to params)

I would have expected this

:parameters {:query {:id "2020"
                      :limit 25
                      :page 0}},
 :params {"id" "2020",
          "limit" "25",
          "page" "0"},

oh wait, I think I get it

ahhhh

it's controlled by the spec!

so whatever is spec'ed out and applied to the route, it'll end up in the parameters map

gotcha

makes sense, and is fantastic!

@paulbutcher would be great if someone had time to re-package the relevant middleware from ring-defauts into reitit-middleware. There are multiple enhancement issues for adding common stuff like cors, security, …). The design question is: how should those be configured? Using route data? Using ring middleware options map? using options map to create a middleware instance?

for reitit 1.0.0 I would like to change all reitit middleware into functions that take no args or options map and return an Middleware instance. Separating the configuration and mounting makes things much easier to understand and allows one to build a single application-scoped configuration.

@max.r.rothman Swagger 2.0 doesn’t understand things like oneOf or anyOf. OpenAPI 3.0 would handle those better, not sure if there are mapping in spec-tool for multi-methods. PRs welcome for those.

Hi all. Although this is more of a question for Muutaja I believe, but I guess here are people that have knowledge of both reitit and Muuntaja... Anyway, anyone knows how could one force Reitit (with Muuntaja setup) to pretty format response JSON/EDN?

By default, JSON is produced in compact form

Is this for a consumer, or for a human?

hmm, i mean, JSON will be consumed by frontend, but for development environment, and debugging purposes, it is good to sacrifice speed/compactness for readability

I normally don't care to make it pretty (to save on a few extra bytes). If I want to view it nicely, I just use httpie or pipe the output to jq on the commandline, in the browser, there are numerous plugins to a browser to prettify the output

httpie is very very good for viewing the output, it'll prettify and colourise as well

http :8080/my/funky/api

yeah, just wanted to make sure that any frontend developer don't need to use any extra tools/plugins, just open Network tab in chrome inspector, and see it pretty immediately

ok, i guess the answer is no..no biggie anyway

Perhaps your frontend dev would use postman or summat to explore APIs anyway

or if they are using graphql, it's built in to the development on a different port

that's what our dev frontend use

combination of postman, or graphql stuff running on the client.

I wouldn't spend cycles on the backend just to make the output nicer for the frontend UIs

ok.....maybe will use some custom middleware if I really need this

I guess it's feasible, muuntaja can be supplied with of options that would influence cheshire, perhaps try passing in :pretty true as an option to the configuration map for muuntaja

report back when you get it to work 🙂

In fact it should be as simple as something along the lines of (from top of my head, not tested) :muuntaja (m/create (merge m/default-options {:formats {:encoder-opts {:pretty true}}}))

here you go

:muuntaja (m/create (-> m/default-options
                                   (update-in [:formats "application/json"]
                                              merge {:encoder-opts {:pretty true}})))

That will prettify the output