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

hello again

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

so it makes sense to set consumes and produces to application/octet-stream

but if there is an error, say an unsupported file extension is being PUT, I might want to return error details

octet-stream is not the best for that

so in error cases I would want to return something more meaningful like json or edn

This brings up a few questions:

- As content negotiation will happen before some of these errors are detected, can I override the already negotiated content type?

- Do I need to advertise the content types I only use for error reporting?

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

hmm

my previous statement might not be true

okay, I just found out that you can specify :consumes and :produces per method if you wish to

that does help

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

nice one

one possible problem I see is when your supported happy path representations are different to your error path representations

GET, normally serving binary but serving errors in json

https://github.com/juxt/yada/blob/master/manuscript/090_responses.md#status-responses

oooh

I like that

+

yada is awesome

data is awesome :)

that too

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 ?

@mccraigmccraig yes