This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-18
Channels
- # admin-announcements (1)
- # aleph (3)
- # beginners (20)
- # boot (9)
- # cider (74)
- # clara (1)
- # cljs-dev (28)
- # cljsrn (15)
- # clojars (32)
- # clojure (149)
- # clojure-dusseldorf (3)
- # clojure-italy (6)
- # clojure-nl (3)
- # clojure-russia (20)
- # clojure-uk (5)
- # clojurescript (133)
- # core-async (2)
- # cursive (19)
- # datomic (24)
- # devcards (1)
- # funcool (100)
- # hoplon (48)
- # keechma (1)
- # kosmos (7)
- # ldnclj (3)
- # leiningen (3)
- # luminus (16)
- # off-topic (8)
- # om (103)
- # onyx (47)
- # pedestal (3)
- # proton (7)
- # re-frame (13)
- # reagent (11)
- # ring-swagger (1)
- # specter (6)
- # testing (12)
- # untangled (24)
- # yada (32)
thanks - I need to update http://yada.juxt.pro - having slight issues with vhosts for that which I'm fixing. In the meantime please use https://github.com/juxt/yada/blob/master/manuscript/030_hello.md
I'm implementing an api endpoint that accepts and serves binary files (Content-Type: application/octet-stream plus the Content-Disposition header)
under normal circumstances your PUT operations would result in 204 No Content and your GETs in 200 with the file as the content
but if there is an error, say an unsupported file extension is being PUT, I might want to return error details
- As content negotiation will happen before some of these errors are detected, can I override the already negotiated content type?
In fairness, this is a strange endpoint alright. If we look at only the happy paths, PUTs don't need to have produced content-type as they should not return content
I could specify edn and json as produced for the sake of PUT but then what would prevent someone from specifying edn in Accept for a GET?
Correction: now that I dived into the yada code I see that select-representation happens after the request body is processed so I might be able to do something there
okay, I just found out that you can specify :consumes
and :produces
per method if you wish to
@imre upon error, yada will re-negotiate the content type. Your status responses can declare their own :produces. The only thing that remains constant is the user agent's Accept header. This design is born of the painful experience we had trying to do this in Liberator, which was somewhay constrained by the webmachine graph.
one possible problem I see is when your supported happy path representations are different to your error path representations
https://github.com/juxt/yada/blob/master/manuscript/090_responses.md#status-responses
data is awesome :)
There's been some memory exhaustion issues with yada (actually netty) at scale lately but we may have solved them. Anyone in @channel experiencing any issues please get in touch
@malcolmsparks: were the mem issues related to async file upload ?