This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-29
Channels
- # beginners (42)
- # boot (12)
- # cider (3)
- # cljs-dev (277)
- # cljsrn (44)
- # clojure (127)
- # clojure-austin (9)
- # clojure-austria (1)
- # clojure-brasil (14)
- # clojure-canada (1)
- # clojure-dev (22)
- # clojure-dusseldorf (1)
- # clojure-italy (4)
- # clojure-russia (24)
- # clojure-spec (33)
- # clojure-taiwan (1)
- # clojure-uk (21)
- # clojure-ukraine (8)
- # clojurescript (134)
- # core-async (41)
- # core-logic (8)
- # cursive (1)
- # datomic (3)
- # ethereum (1)
- # events (4)
- # funcool (1)
- # leiningen (12)
- # off-topic (21)
- # om (19)
- # onyx (45)
- # overtone (1)
- # parinfer (2)
- # pedestal (3)
- # proton (2)
- # re-frame (103)
- # reagent (48)
- # test-check (27)
- # untangled (51)
- # vim (3)
an HTTP question - i'm creating a sub-resource which causes some upstream actions which may fail, despite the creation of the sub-resource being successful (registering a phone # against a user sends an SMS to the user, which may fail) ... what's the best way of indicating this to a client, which needs to be able to present a "we registered your phone#, try again later for the SMS" to the user... i could use a 502, but 502s can happen for other reasons, so could be a pain to process... does it sound reasonable to put a status-description structure into a 201 to indicate a qualified success ?
I really think of 5xx as being for truly exceptional things and these don't sound like exceptions as such.
no, something good happened, just not all the good things the user asked for
actual end-point applications can’t do enough from response code alone, and have to make sure intermediaries aren’t sending responses that happen to have the same code - so they need to inspect the body anyway
I think something 2xx and then enough info for the client to decide what (if anything) to do
yeah, that's the way i'm leaning too
maybe a 201 with a location to where the result of the upstream actions will be available
I like @tcoupland ’s idea…
I'd reply with either a 201
or 202
depending on the specifics... 202 is good for communicating that the request was recorded - but its success or failure isn't really known yet - usually because of asynchrony.
but I'm guessing you don't consider the action to have failed if the sms isn't sent... so 201 is probably best
yeah, it has partially succeeded if the sms isn't sent, but the user will want to re-send the sms at some point later
i went with 201
Some things will automatically raise alerts on 5xx - definitely avoid! I think 2xx + payload is the way to go.
https://http.cat <- choose the cat which seems most appropriate to what you want to do. then use the code it represents