REST Basket

Question

Can I implement a shopping cart using REST architecture restrictions?

I would like to focus my question on the state of the session. In a typical MVC application that implements a shopping cart, most likely the session object will be managed in the session, the shopping cart is in the form of a list of products.

How can I manage the same shopping cart if the application has implemented the REST architecture. One of the limitations of REST is government administration - this is the responsibility of customers.

Should I manage and manage my shopping cart? Any examples? Any flaws in managing customer status in relation to a simple shopping cart or any other corporate application?

Answer 1

There is nothing wrong with keeping a shopping cart as a resource on the server. This is the session state that should be stored on the client. https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3

To be stateless, your shopping cart URI must be able to identify a unique shopping cart without having to rely on session information.

For example, /shopping-cart is probably not enough if your application does not have only one shopping cart.

There will probably be at least one cart for each user. So you can use something like /user/1234/shopping-cart or /shopping-cart?userID=1234 .

It is more likely that you will probably need several shopping baskets for each user. Thus, you want to provide your carts with a unique identifier, for example /user/1234/shopping-cart/5678 or just /shopping-cart/5678 .

The fact is that everything necessary for processing the request should be in the request.

Answer 2

In REST applications, the state of the session is completely controlled by the client, and the request must contain all the necessary information for the server to understand. If the server requires authentication, for example, each request must contain credentials.

An unrestricted REST value is defined as the following:

5.1.3 stateless

[...] each request from the client to the server must contain all the information necessary for understanding the request, and cannot use any stored context on the server. Thus, the session state is fully maintained by the client. [...]

However, the restriction without saving does not mean that the server should not store any data.

In applications in which the session state is managed by the server, this is a general approach that stores shopping cart data in an HTTP session. But the basket is not a session. And, probably, it should not be completely controlled by the client.

In REST, a shopping cart, there may be a resource identified by a URL, such as /shopping-cart , and operations can be performed on it. All shopping cart data can be stored in a database on the server.

Any information that can be named can be a REST resource , even a shopping basket:

5.2.1.1 Resources and resource identifiers

Key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporary service (for example, "today is the weather in Los Angeles"), a collection of other resources, not a virtual object (for example, a person), etc., by others in words, any concept that may be the subject of an author’s hypertext link must meet the definition of a resource. A resource is a conceptual comparison with a set of objects, and not with an entity that corresponds to a mapping at any particular moment in time. [...]

You can perform such operations in the basket:

• GET /shopping-cart : Get a basket.

• POST /shopping-cart : add the item to the shopping cart (send some data with the item to be added and the quantity in the request body).

• DELETE /shopping-cart/1 : remove item with identifier 1 from shopping cart.

• PATCH /shopping-cart : update the shopping cart (sending some data for updating to the request body).

• PUT /shopping-cart : Replace the entire contents of the shopping cart (send some data with the contents of your shopping cart to the request body).

• DELETE /shopping-cart : delete the shopping cart

• POST /shopping-cart/order : Order the contents of the shopping basket

So, observe that the customer will not store information about the shopping cart at any time. All information related to the basket will be stored on the server.

---

For more information on REST, I recommend reading Chapter 5 of Roy T. Fielding dissertation .

Answer 3

There is a lot of confusion in REST because many people hear about the limitations of REST and consider them to be rules that apply for no reason other than following architecture as an end in itself.

The real question you should ask is why in REST there is a limit without limits, and what are the benefits you get from doing it. Keep in mind that REST is an architectural style designed for the long-term evolution of large-scale distributed systems. You simply won’t have the problems that REST needs to solve in a small application where one database contains all your information.

A stateless restriction causes the property of visibility, reliability, and scalability. Visibility has been improved because the monitoring system should not go beyond just requesting data to determine the full nature of the request. Reliability improves because it facilitates the task of recovering partial failures. Scalability improves because the storage state between requests is not required, which allows the fast server component of free resources and further simplifies implementation, since the server does not need to control the use of resources between requests.

Thus, being a stateless person, a client request must have all the information necessary for its processing.

How important is visibility to you? Do you want to see the entire contents of the shopping cart with a customer request when you are debugging something, or is it good that you need to get this information from the databases?

How important is reliability? You have a large distributed system with several servers and databases, where is it important? If you have a large distributed system in which shopping cart information can be stored in different databases depending on the exact HTTP server that answered the request, if the server fails, only another server from this group will be able to fulfill the request and end the session , or a server from another group will force the client to restart the session. If all the information is contained in the request, then any server can do this.

How important is scalability? If you have a distributed system and you store information about a shopping cart in one database, it becomes a funnel for all your queries and you lose scalability. If you store it in several databases, you lose reliability, as described above.

So, do you have ambitious long-term goals, or will your application be big enough to run into problems that try to solve REST? If you always have several servers and one database, and you will use them for each individual request, it does not matter whether you become stateless or not. You can simply have the resource /shopping_cart or something like that, add material to it using POST requests and close or delete it when you are done.

If your data will be distributed across several databases, there are many HTTP servers responding to requests, cache servers, etc., and you want to be able to dynamically create capacity by setting up new servers as needed and removing them while reducing load, then go to full stateless and leave the basket with the customer.

Answer 4

Yes, you can,

Shopping cart data (added products) can be stored in a customer session, which is not a problem.

Then, as soon as the user clicks / checks, the shopping cart should be stored in the database on the server. The key to relaxation is that every application that a client makes must contain all the data in order to identify themselves, I suggest reading something about JWT or OAuth.

The application itself will work like any other shopping cart application that you saw, most of them are not saved in the shopping cart in the database, just save it in the customer session.