|more useful options|
First off, REST and capability based security are separate issues. You can have either one without the other. I like REST, but I'll ignore it from now on and just talk about capabilities.
Let's use a hypothetical message board system to illustrate the differences in style between an access control list model and a capability based model. People can read messages, add new posts, administrators can edit them, etc.
In a traditional Access Control List security model you would have different users, each of which has different permissions, so you'll do things like this:
You have a single user that has permission to do one or more operations.
With an capability model you ask for the capability to do something - and get given an object that will let you do the operation.
You have multiple capabilities each of which allows you to perform individual operations
Why do it like this? Because it gives you great advantages in the granuality and scope of your security model.
Let's do a hypothetical task with our board system - create-table-of-contents.
We want to have a message on the board that contains a list of all the subject lines of the posts on that board. To do this we need to:
With an ACL model you would have run our create-table-of-contents routine with a user who can both get and set messages.
The disadvantage of this model is that the bit of code that reads the subjects doesn't need the ability to write posts. Equally, the bit of code that needs to update the table-of-contents message does not need the ability to read posts.
If you make a mistake in your reading code (or a malicious user subverts it somehow) then you can make unwanted changes to the contents of your board.
With a capability based model you would only give find-subjects the "get" capability object. You would only give update-toc the "set" capability object. Even if an evil user subverted find-subjects they wouldn't be able to make changes to the board since it lacks the appropriate capability object.
Having this fine level of granuality makes tweaking your security model so much easier. For example, we might discover that our admin users wander off leaving themselves logged in - allowing nasty people to come use there account to change posts.
With our ACL model one option is to expire the user if there has been no activity in 10 minutes. Unfortunately, this annoys our admin users since they spend most of the time doing "normal user" things and don't like to find themselves logged out all of the time.
With our capability model we have finer control and we can expire the "set" capability object after ten minutes inactivity - leaving the users "normal" capabilities still in full affect.
There are lots of variations on this sort of thing. Without knowing more about the particular problem you are trying to address it's hard to say whether ACLs or a Capability model would be better for you - but hopefully this makes the concept easier to get a handle on ;-)