Fork me on GitHub
#ldnclj
<
2016-02-24
>
malcolmsparks09:02:26

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

rickmoynihan09:02:50

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

rickmoynihan09:02:31

I've just checked and indeed it looks like compojure matches the method before it matches the route.

glenjamin09:02:56

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

malcolmsparks09:02:01

yeah, I've said compojure gets it wrong, and I stand by that. But actually, almost everyone else gets it wrong too.

malcolmsparks09:02:02

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.
from http://allblackadderscripts.blogspot.co.uk/2012/12/blackadder-ii-episde-3-potato.html

glenjamin09:02:49

i suppose it depends how bothered about 405 responses you are

rickmoynihan10:02:18

@malcolmsparks: myself included it seems! simple_smile

malcolmsparks11:02:49

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

glenjamin11:02:15

this assumes you’re building a service which operates / thinks in terms of resources

glenjamin11:02:27

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

malcolmsparks11:02:33

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)

glenjamin11:02:53

i don’t disagree there

glenjamin11:02:22

Although I can’t think of many cases where a user agent would be able to react differently to a 405 vs a 404

mccraigmccraig11:02:37

@glenjamin: as the developer of a client i would react differently to a 405 than a 404

glenjamin11:02:16

can you give an example? aside from a different error message, I can’t think of any way to take alternative remediary action

mccraigmccraig11:02:00

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

glenjamin11:02:29

ah ok, that makes sense

minimal11:02:34

sometimes you just want the headers but not every api supports HEAD so you have to fall back to get

rickmoynihan12:02:58

yeah a 405 is useful for a developer to see - even without a response body saying what wen't wrong

rickmoynihan12:02:28

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

otfrom13:02:46

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)

glenjamin13:02:56

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

glenjamin13:02:46

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

otfrom14:02:04

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

otfrom14:02:29

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

rickmoynihan17:02:57

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?

otfrom17:02:02

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)