A resource representation is usually generated at request time - {:response (fn [ctx] ...)} but doesn't have to be {:response "Hello!"}

@richiardiandrea: They can return promises (but don't have to).

The execution order is defined in yada.handler/default-interceptor-chain - https://github.com/juxt/yada/blob/master/src/yada/handler.clj#L234

So :properties is called before :response. The job of properties is to define meta-data about the resource, which is used as input to the semantics of the method. For example, :version and :last-modified determine whether a 304 Not Modified can be sent for a GET request. It is OK for a properties function to go off to the database to determine this metadata, and in doing so it might be that the resource content is loaded too (and added to the context). Or the response can re-visit the database - it all depends on the type of resource you are building.

:response does not have a :properties subkey - are you sure you said that right?

:exists? is true by default, you only provide it if it's false (or possibly false).

For example, does /accounts/12345678 exist? That might depend on whether the account 12345678 actually exists, and perhaps also that the request holds the credentials of the authorized account holder.

So in that case, exists? would need to be dynamically produced. You could return nil in the response function too, but I prefer the exists? check because it prevents the :response function being called and relying on the programmer to not reveal the account details to the wrong person.

You can separate these concerns by using exists?

@malcolmsparks: thanks for the detailed answer! I will try again, but one thing I noticed yesterday also was that in the context passed to : properties I did not have my :id as neither form/query/path... But again, I am newbing here so I might be doing something wrong 😃

@richiardiandrea: parameters are parsed before the properties call so you should see them in the context. I suggest you try logging (:parameters ctx)

Yeah that's what I did from inside the properties callback but i don't want to say anymore incorrect things before trying again ok ? 😃😂😃

HEAD requests seem to always return 200. This is problematic when implementing a health-check. How do I specify the HEAD status in the resource?

@joshg: you can return the response from (:response ctx), modified if neccesary, from a response callback.