Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

REST Shopping cart

Tags:

rest

Can a shopping cart be implemented using REST architecture constraints?

I would like to focus my question with respect to session state. In a typical MVC application implementing a shopping cart, it most likely, session object will be managed in session, shopping cart as a list of products.

How would this same shopping cart be managed in if the application had followed REST architecture. One of the REST constraints is state management is responsibility of clients.

Should a shopping cart and it's progress be managed by client? Any examples? Any disadvantages of managing state in client with respect to a simple shopping cart or any other enterprise applications?

like image 504
Sat Bobbi Avatar asked Nov 18 '15 17:11

Sat Bobbi


2 Answers

There is nothing wrong with storing the shopping cart as a resource on the server. It is 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

In order to be stateless, your shopping-cart URI should be able to identify a unique cart without needing to rely on any session information.

For example, /shopping-cart is probably not sufficient unless there will only ever be one shopping cart throughout your application.

Likely, there will be at least one cart per user. So, you could use something like /user/1234/shopping-cart or /shopping-cart?userID=1234.

Even more likely, you will probably need to have multiple shopping-carts per user. So, you will want to give your carts a unique ID like /user/1234/shopping-cart/5678 or just /shopping-cart/5678.

The point is, everything needed to process the request should be in the request.

like image 194
Jason Desrosiers Avatar answered Sep 28 '22 04:09

Jason Desrosiers


In REST applications, the session state is entirely managed by the client and the request must contain all the necessary information to be understood by the server. If the server requires authentication, for example, each request must contain the credentials.

The REST stateless constraint is defined as the following:

5.1.3 Stateless

[...] each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. [...]

However, the stateless constraint doesn't mean the server shouldn't store any data.

In applications which the session state is managed by the server, it's a common approach storing the shopping cart data in the HTTP session. But a shopping cart is not a session state. And, probably, it should not be entirely managed by the client.

In REST, a shopping cart, can be a resource identified by a URL such as /shopping-cart and operations can be performed over it. All the shopping cart data can be persisted to a database on the server.

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

5.2.1.1 Resources and Resource Identifiers

The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time. [...]

You can perform operations like these on your shopping cart:

  • GET /shopping-cart: Get the shopping cart.

  • POST /shopping-cart: Add an item to the shopping cart (sending some data with the item you are adding and the amount in the request body).

  • DELETE /shopping-cart/1: Remove an item with id 1 from the shopping cart.

  • PATCH /shopping-cart: Update the shopping cart (sending some data to be updated in the request body).

  • PUT /shopping-cart: Replace the whole content of the shopping cart (sending some data with the content of your shopping cart in the request body).

  • DELETE /shopping-cart: Remove the shopping cart

  • POST /shopping-cart/order: Order the shopping cart content

So, observe the client won't store any information about the shopping cart at any time. All the information related to the shopping cart will be stored in the server.


For more information about REST, I do recommend reading the chapter 5 of Roy T. Fielding's dissertation.

like image 33
cassiomolin Avatar answered Sep 28 '22 03:09

cassiomolin