Fork me on GitHub

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


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


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


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