@grzegorzrynkowski_clo mw are applied in the order they are defined, and the order can matter. For example, the content-negotiation needs to happen before request or response formatting.

mw could be reordered automatically based on their requirements, there is a helpers to build such a dependency system.

@ikitommi re the mw order: 1. in this case, shouldn’t parameters parameters/parameters-middleware in the ring-spec-swagger example be listed later in the vector (after the muuntaja entries)? (https://github.com/metosin/reitit/blob/master/examples/ring-spec-swagger/src/example/server.clj#L88) 2. Since the exception-middleware doesn’t react on requests directly (but in response to handlers or middlewares error), shouldn’t it be first in the vector of middlewares? (https://github.com/metosin/reitit/blob/master/examples/ring-spec-swagger/src/example/server.clj#L94)?

are there any examples of using reitit to handle routes for a client side http library? would such a thing work?

I would suggest other libraries such as clj-http or clj-rest-client etc...

@ramblurr sure: https://github.com/metosin/reitit/tree/master/examples/frontend and others from the examples folder.

@rgm that's not quite what I mean. That's for frontend routing in the browser, which is essentially the same concept as backend routing in a rest api. What I'm pondering is using reitit as the framework to build up a library for interacting with an existing HTTP API. Somehow using reitit defined routes to generate request maps to be passed to clj-http

Oh I see. Sorry. Didn’t quite grok that.

There’s an href generator in frontend.easy ... do you mean something like that? https://github.com/metosin/reitit/blob/master/examples/frontend-re-frame/src/cljs/frontend_re_frame/core.cljs

(See line 74)

sort of yea, that's a nice example of using reitit in a different way

@ramblurr would you use reitit on the client side to describe paths in any server or a just for a reitit backend?

for a reitit backend, you can use shared routes. For more dynamic system, this could be useful: https://github.com/metosin/reitit/issues/227

for full integration, all the information (parameters, auth) should be exposed. Swagger is providing one such tool...

In this particular case it would be to describe paths of a non-reitit backend. However for other scenarios we have, using it against a reitit backend would also be useful

for this particular task I'm working on, I have a rather large and complicated third-party http api, and I want to define it as data, then be able to operate on it with param coercion.

sounds good, you should be able to build such a (data-driven) client with reitit. Just build on top of the core router + coercion.

... and can use middleware or interceptors too in the client side, just like clj-http does

yea, and the user will primarily use functions that call match-by-name

if the legacy app already does swagger/openapi, you could use something like Martian (https://github.com/oliyh/martian).

but definetely interesting, happy to help if you need anything.

could be a example or module once finished?

oh martian is interesting! thanks for that link. unfortunately this service doesn't have a swagger definition, but that would come in handy

actually it looks like martian has a way to manually bootstrap it without swagger

one reason for us tl start developing malli (https://github.com/metosin/malli) is to be able to serialize data model definitions over the wire: here, servers could expose all their route info to clients, which could mock those locally, generate uis etc

Last time I checked, Martian used best-effort reverse engineering with schema for existing apis. Gives ok'ish results. The bootstrapping uses schema locally and is more sound.

hm, yea i'd rather stick with spec as we already use it.

will continue with the reitit experiment