This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # aleph (3)
- # announcements (4)
- # beginners (30)
- # boot (296)
- # cider (21)
- # cljsjs (2)
- # cljsrn (18)
- # clojure (124)
- # clojure-poland (23)
- # clojure-russia (4)
- # clojurescript (73)
- # core-async (58)
- # css (3)
- # datomic (31)
- # editors (4)
- # emacs (35)
- # euroclojure (3)
- # hoplon (104)
- # immutant (8)
- # jobs (3)
- # jobs-discuss (1)
- # keechma (1)
- # ldnclj (33)
- # leiningen (5)
- # liberator (1)
- # mount (20)
- # off-topic (2)
- # om (104)
- # onyx (54)
- # parinfer (80)
- # proton (1)
- # re-frame (59)
- # remote-jobs (1)
- # ring-swagger (9)
- # slack-help (15)
- # spacemacs (7)
- # yada (12)
@rickmoynihan: I don't know where you heard about matching verbs before routes, strictly speaking (in HTTP) a verb has nothing to do with routing to a resource, it's interpreted by the resource itself.
@malcolmsparks: I think I've actually just recalled it the wrong way... IIRC somebody somewhere - possibly even you in the context of yada/liberator/bidi vs (or in combination with) compojure - mentioned that compojure gets it wrong and does it the wrong way round... and I've just misrecalled what the right way was...
I've just checked and indeed it looks like compojure matches the method before it matches the route.
yeah, I've said compojure gets it wrong, and I stand by that. But actually, almost everyone else gets it wrong too.
Edmund: I was under the impression that it was common maritime practice for a ship to have a crew. Rum: Opinion is divided on the subject. Edmund: Oh, really? [starting to get the picture] Rum: Yahs. All the other captains say it is; I say it isn't. Edmund: Oh, God; Mad as a brush.
@glenjamin: I think it's more the fact that a resource really ought to know which methods it supports (it's meant to reveal that in the Allow response header to an OPTIONS request). But for other reasons too - mostly it's because it's part of the http model - and reinterpreting that model seems wrong to me, even for pragmatic reasons.
this assumes you’re building a service which operates / thinks in terms of resources
yes, i'm sympathetic to pragmatic approaches, but it seems to me that there are a ton of pragmatic libraries and not too many pure ones - over time that degrades http (at a time when we actually need many of its features more than we used to)
Although I can’t think of many cases where a user agent would be able to react differently to a 405 vs a 404
@glenjamin: as the developer of a client i would react differently to a 405 than a 404
can you give an example? aside from a different error message, I can’t think of any way to take alternative remediary action
i'm not talking of an automatic reaction... just that if i see i'm getting a 405 then i know that i probably need to POST instead of GET or whatever, whereas if i see a 404 then i figure i got the url wrong. this is helpful if i'm not controlling the api
sometimes you just want the headers but not every api supports HEAD so you have to fall back to get
yeah a 405 is useful for a developer to see - even without a response body saying what wen't wrong
a 405 might also depend upon the state of a resource. It might be something in a locked period (future or past or too close to now to do PUT/DELETE or other to)
412, not sure what the difference between those is supposed to be, reading them now
428 seems to be more about managing concurrent requests, whereas I'm thinking about something where there might be a time range or something beyond the clients that changes what can be done w/a resource
agreed - but presumably only with regards to the HTTP method tried... e.g. returning 405 "locked for writes" on a POST because the resource has writes disabled seems legit... though I guess you might need to look at using an appropriate entity header to indicate that it was just a temporary state not a permanent one?