I have this data tool and I'm trying to create an interface for it, so I'm trying to write a server

I'd like it to print some text output if you curl, and some markup if you access it another way

(defroutes app-routes
  (GET "/" [] (html (view/last-night [])))
  (GET "/agent" {:keys [headers params] :as request}
       (if-let [agent (get headers "user-agent")]
         (str "Your user agent is " agent)
         (html [:div.agent
                [:h2 "Welcome,"]
                [:p "Mysterious friend"]])))
  (GET "/pipeline/:id" [id] (html (view/pipeline id)))
  (route/not-found "Not Found"))

In these routes, I've figured out how to get at the headers in the /agent route. And I've figured out how to get data out of the URL in the /pipeline/:id route

Can these be combined? E.g., can I have a route /pipeline/:id that accesses the headers?

I've looked at the Compojure Destructuring document but, I'm not clear on whether that :id is a 'param' or not

If you use functions as handlers, instead of just code blocks, they will be passed the whole Ring request hash map.

The declaration of variables in routes -- [id] in your code -- is good for coercion of parameter types and documentation (and very, very simple handlers) but not much use beyond that really.

So your handlers could be (fn [{:keys [headers params] :as request}] …) or named functions.

Does that help @mathpunk?

kiiiiind of.... does that mean that the segments of the URL are in the request itself?

like I'm just looking at this form, (GET "/pipeline/:id" [id] (html (view/pipeline id))) and it looks like magic that turns "a bit of URL in the browser bar" into "a bound var"

so, if use that destructuring form, I'm responsible for splitting up (:compojure-uri request) myself

(GET "/pipeline/:id" [] show-pipeline) where

(defn show-pipeline [{:keys [headers params] :as request}] (html (view/pipeline (:id params))))

ok I think I see it

I try to avoid Compojure's destructuring to be honest -- it isn't powerful enough in the general case.

I didn't realize that the params and the URI had anything to do with each other.... my mental model was, "headers are key-value pairs you're not shown, and params are things after a question mark"

hmm... I have tried using Ring directly but I very quickly got overwhelmed by options I didn't understand

(there's a lotta stuff in a request and a response)

Looking at the source code, I'm not quite sure how it ends up working with function values in the handler slot (but it definitely does) so I need to play with macroexpand in the REPL a bit...

...ah, OK, I get it now. So the bound symbols are available literally in the handler form, whatever that is, so this would work:

(GET "/pipeline/:id" [id] (fn [req] (html (view/pipeline id))))

(I've never bother to dig through the source to understand it before -- "It. Just. Works." so I haven't needed to)

@mathpunk Just as a follow-up

user=> (GET "/pipeline/:id" [id] (fn [req] (println 'id id) (println 'req req) "Hi!"))
#object[compojure.core$wrap_route_matches$fn__2291 0x76134b9b "compojure.core$wrap_route_matches$fn__2291@76134b9b"]
user=> (*1 {:uri "/pipeline/42" :request-method :get})
id 42
req {:uri /pipeline/42, :request-method :get, :route-params {:id 42}, :params {:id 42}, :compojure/route [:get /pipeline/:id]}
{:status 200, :headers {"Content-Type" "text/html; charset=utf-8"}, :body "Hi!"}

O_O

I have grabbed all of this text, put it somewhere safe, and I will stare at + experiment with it 🙂

If the binding form is a vector, it just binds the route parameter values it seems. If the binding form is a hash map, then it binds the whole request map.

That was one of the pieces I was missing.

thanks Sean! helpful as always 🙏:skin-tone-2:

Helping other people often teaches me new stuff and improves my understanding of tech. I'm not as altruistic as people might think 🙂

hahaha