> How do you deal with non-CRUD operations?
There is no such thing as a non-CRUD operation in a well-modeled domain. Actions in the domain are entities in the model and, therefore, are subjects of CRUD operations (often just Create and Read, but Update and Delete can also be sensible.)
> How do you deal with long running processes?
As entities that can be Created and Read.
> Or entities in an indeterminate state?
By returning a representation of the applicable wavefunction.
> How do you aggregate multiple resources into individual request/responses for performance?
By defining resources that are aggregates of other resources, and including, among the available representations for such resources, representations that include the subelements directly rather than only by reference.
This is analogous, in the RelationalDBs, to defining views (or set-valued functions, depending on the type of aggregation you are doing.)
> How do you de-duplicate identical entities within an aggregated response?
Whether or how you do this depends on the representation chosen.
> How do you return only particular fields?
By returning a representation that includes only the projection of the base resource that is of interest. I suspect the question you mean to ask, however, is how you specify a request for such a projection in REST over HTTP (REST is not tied to a particular protocol, but HTTP is the most popular one used with the architecture, and does have some particular issues in this particular case), and there are a couple of obvious alternatives:
1) Treat this as a request to create a subordinate resource to the base resource, and do it via POST, or
2) Recognize that this (like the use case met now by PATCH) is a gap in the existing HTTP method set that requires a workaround, and add a HTTP extension method (preferably, one proposed as an RFC with general semantics), such as something similar to WebDAV's REPORT or SEARCH (but not so application-specific.) REST doesn't -- with an extensible protocol like HTTP -- mean you have to be limited by the base protocol, it just means you have to be judicious in your use of extensions. [0]
> How do you handle paging and filtering?
Same answer as the previous question (in fact, paging and filtering are essentially the same thing as the previous question.)
> How do you handle transactions?
A unit of work that is logically linked in the domain is an entity in the domain that can be Created, Read, Updated, and Deleted (particularly C = BEGIN , U = COMMIT, D = ROLLBACK.) Actions within the transaction can either reference the transaction in resource representations or be subordinate resources to the transaction itself, depending on context.
> How do you handle authentication and security restrictions?
Generally, Authentication is communications-protocol dependent and how security restrictions are enforced is outside of the scope of REST.
[0] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... : "A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as HTTP’s PATCH method or Link header field."