Clojurians Log v2

@yannvahalewyn REST doesn't dictate url shape. Maybe something like /resource/new and /resource/items/:id could work?

Could you have one route, then deal with the different cases inside the handler?

(def routes
  ["phone/data/:seg"
   {:get (fn [{:as request {:keys [seg]} :path-params}]
           (case seg
             "specific" (handler-specific request)
             (handler-other request)))}])

The route data and parameter specs/validation is different, otherwise i would do it like you suggest

I am actually using {:conflicting true} myself in my route tables, but I’ve considered this as an alternative. In my project I’m still nailing down the specific routes, but once that is sort of finalized, I’ll see what tweaks I can make and hopefully won’t need to allow conflicts.

@eoogbe Indeed rest is not a protocol and yes those would work. But there are common conventions adopted when making restful url schemes as described https://restfulapi.net/resource-naming/ and seen in this https://medium.com/@shubhangirajagrawal/the-7-restful-routes-a8e84201f206 . For me keeping the convention of /products/:id is usually worth the conflicting route 🙂

I've been experimenting with a naming convention that doesn't have conflicts: • GET /product/items - Show list of products • GET /product/new - Show form to make new product • POST /product/items - Add product • GET /product/items/:id - Show single product • GET /product/edit/:id - Show form to edit product • PUT /product/items/:id - Update product • DELETE /product/items/:id - Delete product

I also use {:conflicting true}. I have this for /resource/new and /resource/:id paths. If someone knows how to do REST without :conflicting I'd love to hear how

> If someone knows how to do REST without :conflicting I'd love to hear how Could you differentiate between HTTP verbs?

According to REST, new and show are both GET requests and this is also preferable for semantics and browser support.