I am unsure, if I understand the principles of REST completely.
The idea behind it is (according to e.g. Wiki and other sources) that data is transferred via HTTP(S) and addressed via URIs. Depending on the HTTP method used different operations on the underlying database are performed (CRUD operations). The glory details about different representations etc I neglect here for good reason.
This is clearly only a very minimalistic description of a REST API but as far as I see it here, it only represents a transparent "proxy" to access the (SQL) database using basic HTTP actions. So it provides the database access via API. Nothing more.
Is all business logic located on the client? Then I do not see the benefit of using such an architectural structure compared to other paradigms.
To understand things a bit more in detail, I want to describe a bit my idea and what I think might be a way to get it working:
I have a set of users A through D. Each user represents its own client. USers A through C now create some data and put this data in the database. This can be simply represented using the above mentioned structure, I agree.
Now after this is finished, user D comes into action. He has a set of rules (call them laws) and can make a series of decisions based on the data from A-C. All these desicions have to be documented in the database and influence the following options (according to the rulesets).
Now, I can make the following:
- Send the complete data from users A-C to user D and let the client's app handle all the business logic and send the result to the server back. So after each decision the client sends the intermediate result to the server.
- Keep the business logic on the server. The user D gets only a condensed version of the data of A-C. He makes a decision and transfers it to the server. The server applies the rules and provides the options to the user D on request.
I think the first approach is critical as the user might change the business logic and send invalid data to the database through the CRUD interface. The server will not be able to detect this and accept the raw data.
On another quesion of SE (https://softwareengineering.stackexchange.com/a/323343/58867) it is suggested that the business logic is written on the server and to reduce overhead partly on the client. This last part is the part that contradicts my understanding of REST (see above).
- How is it possible to add more layers to abstract a problem using REST?
- How can one model a series of operations (one decision must be made before the next can be addressed) without transferring the whole database on each step (stateless operation)?
- The server is never stateless as he has access to the data. How is this compatible with the requirement of a stateless server?