1) REST is not suited to complex multi-variable queries or transactions
2) REST should be a stateless transaction
3) REST read results should be cacheable
4) REST can use headers to specify content-type/mime-type
REST is not a suitable replacement for all client-server interactions e.g. complex, sql-like queries over many variables. It is best suited to URL-like queries that produce singleton docs or lists of doc IDs.
REST in its most common form is a protocol over HTTP and thus can (and should) take advantage of HTTP's methods to provide CRUD:
Create = POST
Read = GET
Update = PUT (although POST is fine)
Delete = DELETE
> REST is not suited to complex multi-variable queries or transactions
Would it not be possible to represent a query or transaction as a resource, that you could GET/PUT like any other?
> REST should be a stateless transaction
I think there's a small grey area here around "stateless transaction". The HTTP request/response itself should be atomic (to be a bit loose with terminology), but the result can change the state of the system.
So the communication between client and server is the part of the system that is stateless. (Apologies if this was your intended meaning.)
One of the great advantages of REST is that makes data caching easy. Statelessness is a requirement for caching.
"Would it not be possible to represent a query or transaction as a resource"
Anything's possible just about but the whole point of REST is to create uniform resource locators for data. The problem with creating rather forced complicated URIs is that you quickly lose uniqueness: the same data will start being represented by more than one URI and therefore will start to be cached a multiple of times leading to conflicts.
1) REST is not suited to complex multi-variable queries or transactions
2) REST should be a stateless transaction
3) REST read results should be cacheable
4) REST can use headers to specify content-type/mime-type
REST is not a suitable replacement for all client-server interactions e.g. complex, sql-like queries over many variables. It is best suited to URL-like queries that produce singleton docs or lists of doc IDs.
REST in its most common form is a protocol over HTTP and thus can (and should) take advantage of HTTP's methods to provide CRUD:
This negates the need for: or instead use and send it a DELETE method.