2 ms·

For the sake of debate: > REST is not suited to complex multi-variable queries or transactions Would it not be possible to represent a query or transaction as

by bodhi 15y ago

For the sake of debate: > 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.)

sambeau 15y ago
The HTTP request/response itself should be atomic 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.