General question about REST principles

Question

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?

Answer 1

To understand REST you have to understand that there is at least two completely opposing interpretations of it. The first is the "original", from the author who coined it. The arguments from this interpretation are used all the time to justify implementations that do not actually follow it. Then there is the colloquial interpretation of "CRUD through JSON/HTTP".

Because authors rarely say which interpretation they are speaking about, things get really confusing.

To understand the orignal REST, just think about the web and people as clients. On the web, we are presented with options and we choose things from options. I have my own logic (the client logic) I want to achieve, but each resource I talk to may have its own logic. For example I want to book a flight, I may start with google, then go to a flight aggregator site, enter some data (which I don't normally have to enter again!), choose a provider, go there, enter some more data about payment maybe, and so on. I know what I want, and I interact with things in their own domain to do my thing. I have to of course know all of those and understand what they say (Google result page, flight wizard, etc.).

In the colloquial interpretation none of those things matter. You just have some CRUD endpoints and you often hear about URIs, sub-resources, POST vs PUT, and things like that. Rarely if ever are Mediatypes, Links or Forms mentioned, although (original) REST does not exists without Hypermedia.

So now to you questions (and I assume you want the "original" REST, because the colloquial one doesn't really have any specific rules):

1. Where is the business logic: Both the client and server has logic of their own. But, the logic of the server is not be shared with the client. Think of the client as a person. Do you want a person to type in URLs and data with every new request? Of course not, you use Forms, Links, Hidden fields, whatever it takes.

2. How is it possible to add abstractions? Well, how does google search work? How do Wizard dialogs work on the Web? How come you can book a hotel on the web? All those are REST applications, with a human as client. This is not a hyperbole, REST applications with programmatic clients work exactly the same way.

3. How to avoid transferring the whole DB? Again, look at all the millions of web applications. It is not difficult.

4. How is the server stateless? Statelessness != datalessness. State refers to the current interaction, not data. For example if I use a Wizard-type dialog to book a hotel, the progress I make is not tracked (in REST) on the server, instead I resubmit my state each time (via hidden fields, that I don't actually have to know). If I can choose to save a draft version of my booking for example, that is no longer conversational state, the server can very well save that.

Here's an article of mine with some more info: 5 Signs That Your REST API Isn’t RESTful

Answer 2

I am unsure, if I understand the principles of REST completely.

If you want to understand REST completely, you need to be familiar with Fielding's thesis: Architectural Styles and the Design of Network-based Software Architectures.

The REST architectural style "is intended for long-lived network-based applications that span multiple organizations." It is the architectural style of the world-wide-web.

Depending on the HTTP method used different operations on the underlying database are performed (CRUD operations).

That's not quite right; REST doesn't say anything about underlying database. The database is an implementation detail of the server. Part of the point of REST is that the implementation details of the server can be changed without requiring any changes in the client.

Is all business logic located on the client?

No.

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)?

How would you do it on a web site? The client would load up a bookmark, or follow a link, that would take them to a form with a bunch of input fields. Submitting the form would take the client to another page, with more links and more forms, and so on until the work is done.

Each form submission changes the state of a resource on the server.

The server is never stateless as he has access to the data. How is this compatible with the requirement of a stateless server?

Because stateless means something very precise in this context. The server has always been responsible for managing resource state. The important stateless concern is that a single request submitted by the client can be understood by the server without reference to any session state.

Cookies, in HTTP, are opaque tokens typically used to track session state on the server. This is not consistent with the REST stateless constraint. "The same functionality should have been accomplished via anonymous authentication and true client-side state."

Answer 3

The main reason for inventing REST was because client side javascript on websites was unable to make socket connections or deal with xml from traditional APIs easily. But it could make http calls and eval the response.

Even today a lot of of the discussion around REST is from the perspective of a web developer who wants to write minimal 'backend' code.

Thus the focus of CRUD operations and the million and one questions on this site you will find if you search for "How do I limit my API to only my client?"

There is no reason you cant use REST to make RPC style calls to an API