@stijn json rendered errors were temporarily removed for 1.2.x because of rendering issues when errors contained types not possible for cheshire to render. I will look at fixing this.

is there a way to override that behaviour?

Are you prepared to fork temporarily?

possibly, but that's always a hassle with git submodules and lein checkouts 🙂

through :responses maybe?

The issue is that only text/plain is declared so conneg chooses it

but text/html and application/edn seem to work?

Custom responses should be fine

I need to refresh my memory by looking at code.

ok 🙂

I'll go with :responses for now

I will my this my next yada task because it's currently a breakage with 1.1.

I was under a bit of self-induced pressure to release and error handling was sacrificed on the altar of speed. Poor choice in retrospect.

question about authorization on datomic with yada:

I would think it's best practice to do the authorization inside a database function

as e.g. a user might have been blocked, or roles might have been retracted between the incoming call and the actual point of executing the transaction

I deref the connection to get a db value in an interceptor

that would mean I have to (at least for put/post) handle the authorization in the :response instead of using the security interceptors of yada

I think consistency is more useful

@malcolmsparks yes for reads that's ok, but writes

Hmmm

I feel http requests should have ACID properties

Are you doing long async gaps in your requests?

no, but you don't know how fast or slow the transactor is

and you can only guarantee ACID if you let the transactor do the validation

What does Datomic's sync call do. Might be relevant

yes that's a good point. I was just going to write: 'my peer might have a very old db value'

If you're worried about transactor queues, i'd steer clear of tx fns

but still, between sync and transact, something might have changed

there's 2 things that we would like to do inside the transaction: semantic validation of the incoming request and authorization whether the user can update that specific entity

depending on the exception thrown by the transaction, we would generate a 422 (i guess) or a 403.

it's not that bad really, we just wrap every call to d/transact with error handling that will generate the appropriate error codes

but it got me thinking about the split between the authorize and invoke-method interceptors

I guess there will never be a one-size-fits-all HTTP best practice 🙂