@stijn @thomas - when yada calls your GET or POST or whatever method, it does so with the ctx. There is a :response entry in the ctx, which you can modify and return. The :response entry is a Response record. So you can set status, headers and body on that Response and return it. yada will respect whatever you set when you return a Response record. It's a kind of escape hatch so you can always decide to have full control over the response yourself.

Response
  (interpret-post-result [response ctx]
    (assoc ctx :response response))

The nice thing about records is that while they act as maps, if you assoc and dissoc values into them, the type remains.

@malcolmsparks: that's indeed a neat way to return custom responses

The use case for the POST 404 is this: :some is an 'app': a mobile app designated to a certain customer.

I guess a better way to solve this would be to have this as a field in the POST request body, and return a 409 when it's not set to a proper value

I agree that it's hard for yada to take a default approach here

hey @malcolmsparks , i'm getting both yada and ring-swagger errors when trying to specify a schema for a POST body with a map-type with UUID keys - https://www.refheap.com/95c31db2d4ac8d8b2fb9d7913 - before i dive into debugging can you just confirm my thinking that this is a reasonable thing to want to do, and that the errors are spurious rather than by design ?

(prismatic schema itself is quite happy with UUID keys, and i'm currently working around the problem by having a version of the schema with Any keys to get through yada, then coercing with the real schema later)

@mccraigmccraig: does it not allow to specify the schema, or do you get an error on coercion when sending a request?

i get an error on request... tho i can't tell you exactly what right now

that's indeed weird, even String is not accepted as key

s/Any with a String value that represents a UUID is

@malcolmsparks: in the Service protocol, what is the difference between

(authorize [_ ctx] "Authorize the request. When truthy, authorization is called with the value and used as the :authorization entry of the context, otherwise assumed unauthorized.")
  (authorization [o] "Given the result of an authorize call, a truthy value will be added to the context.")