How to maintain state in a Restful service

Question

Below is the sequence of events in a CRUD web service that I am trying to create

Step 1: User request POST /shape/trycreate (try-create request)

Step 2:Controller method receives object :tryCreate(Shape s)

Step 3: Service method returns matching shapes: Collection<Shape> tryCreate(Shape s)

Step 4: If duplicate shape exists throws some exception and ExceptionMapper returns failure response

If returned collection is then empty create the Shape and return SUCCESS response

else if return an object containing paths to view shapes that match the shape user was trying to create to a certain extent and return object also contains a continue path to still create a Shape

So basically response object contains paths like view/Shape/id001 view/Shape/id003 view/Shape/id007 which are Shapes like the Shape s which user was about to create and it also has a continue path create/shape/some-token

Here i think i can use some-token --> Shape object map on the server side where an entry lives for 5 minutes or so. By using this i can validate that a user has not sent a direct request to create but it has gone through the step tryCreate->View Matching Shapes-> Still Create Also it doesn't have to again send the details of Shape in create request which was already sent in tryCreate request.

Now the problem is that using a expiring cache on server side to store validated tokens isn't a Restful design. Q1)**How should i ensure that this is not a direct request to create and it follows a trycreate request **Q2) Do I resend the details of Shape in create request otherwise how do I achieve this?

Thanks

Answer 1

I believe the token approach you mentioned is Ok. The HTTP request is not stateful, its your business logic on the service side that does that. It is like creating an entity and then requesting for it, the two http request are not stateful, but if you have created the entity you will get it in the fetch request, otherwise not.

Can it be just about naming the endpoints, how about:

1) POST /shape/request

2) POST /shape/process

The 2nd is a valid RESTful request as described in this book, terming it as controller resource.

By the say, contrary to the heading, this explains the relation about REST and statelessness.