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 <http://foo?id=2020&limit=25&page=0>
: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.
I thought that reitit’s swagger integration doesn’t support openapi 3.0?
So that means there’s no way to model polymorphic structures in swagger 2.0?
it doesn’t, but both Plumatic & Spec have (some level of) openapi-support now, so would be possible to add support for reitit. would have use for that (but no time to implement)
no, there is not.
there is a dispatch
property for simple cases, but as multi-specs can dispatch on anything, it only works for simple cases.
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 🙂
Thanks for the info, this is super helpful!
Is there any way to get reitit/spec-tools to generate swagger docs using allOf
and discriminator
?
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