The basic idea about REST is to think of your system as a collection of resources (and their representations) which transition on one state to another when acted upon by messages.
REST is a architecture style which applies constraints such as separation of concerns between client and server, support for caching, statelessness, support for multi-hop/redirection of requests etc. The key driver for these constraints is to ensure scalability of the system.
HTTP offers a set of verbs (GET, PUT, DELETE, POST) with universal semantics which can be used to perform operations on resource-representations (URIs) present on the WWW.
A common interpretation of REST when in building web-services is to make the entities being exposed by web-services e.g. Orders, Customers, AddressBooks identifiable using URIs and to map GET, PUT, DELETE, POST to common CRUD operations e.g. Query, Update, Remove, Create/Replace on these resources. This works beautifully when you expose data-services as RESTful APIs.
However this interpretation is non intuitive when you apply REST to non CRUD WS operation such e.g. calculateTax. In this case calculateTax is not a resource. It is a function which acts on a input and produces a output. Whose representation is getting transferred here? What is its URI?
One way to look at it is, consider a resource whose state is the calculated tax for the input user. The calculateTax service produces this resource and returns it to the user. The resource is transient and is not persisted after it is transferred to the client.
Thus the service / API below
- TaxCalculation calculateTax(IncomeDetails incomeDetails)
Can actually be modeled as a GET request for TaxCalculation resource specific to the input IncomeDetails.
Can GET always be used for modeling any idempotent function which does not have any side-effects on the system?