I almost always have both. I tend to use event sourcing and the intent is mandatory. There might be 20 reasons to modify one resource, each with its own list of side effects to later perform.
So it's usually POST resource/:id/action
and that's fine.
> So it's usually POST resource/:id/action and that's fine.
There's nothing wrong with that. It's not anti-REST or anything, assuming you satisfy the other REST constraints, ie. each request is self-contained and any stateful resources are designated by URLs.
As an aside, I'm personally not a huge fan of human-readable URLs because it encourages API consumers to rely on/construct URLs client-side, which is not REST.
I think a more properly-REST approach would be to PUT a representation of the resource with the action applied. That is, rather than POSTing to /resources/:id/close, one would PUT a closed version of the resource to /resources/:id.
I don't see why that would be more REST. POST is to be used for side-effecting operations, PUT is an optimization over POST for idempotent effectful operations.
Certainly a PUT solution might have some advantages for replayability in case of network partitions, but REST doesn't this choice dictate one way or the other.
So it's usually POST resource/:id/action and that's fine.