Clojurians Log v2

morning

@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.

https://github.com/weavejester/compojure/blob/master/src/compojure/core.clj#L133

it’s a common pattern in web frameworks, even though technically incorrect

@rickmoynihan: :simple_smile: that's funny

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.

i suppose it depends how bothered about 405 responses you are

@malcolmsparks: myself included it seems! :simple_smile:

morning

gmawn

@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

which probably should be the case, but isn’t always

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)

i don’t disagree there

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

ah ok, that makes sense

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

so it's useful for a framework to implement that behaviour

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)

hrm, i’d often do something like a 428 for that

or 412, not sure what the difference between those is supposed to be, reading them now

412 looks like it is the requesters precondition (not sure how that is communicated)

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?

rickmoynihan: I'm thinking that it might be permanent from that point, that the resource has reached some final locked state (though if it could change in the future it would be good to have a way of signalling that)