[zinkem]

Idempotency is easy if you don't use mutable state in your middleware.

Auth, logging, and atomicity are all isolated concerns that should not affect the domain specific user contract with your API.

How you handle unique keys is going to vary by domain and tolerance-- and its probably not going to be the same in every table.

It's important to design a database schema that can work independently of your middleware layer.

[ahoka]

So idempotency is easy if your service does not do anything useful?

[mrkeen]

It's just the horrible misapplication of the term 'stateless' to a wrapper around something very-much stateful. It's here to stay.

(Though I do disagree with the original premise too. Putting on a 'stateless' boxing glove won't mean there's no difference between punching a guy once or twice)

[zinkem]

> Putting on a 'stateless' boxing glove won't mean there's no difference between punching a guy once or twice

There are still side effects in the system, of course.

But what your database looks like afterwards is the important part.

Can you recover lost data, replay transactions, undo, etc etc?

[zinkem]

Whether or not your service does something useful is up to you.

A database on it's own is enough for most business applications.

If you haven't seen this yet, you're just rent seeking.