REST API – Is REST Limited to Optimistic Concurrency Control?

Architectureconcurrencydesignrest

Context

Due to the statelessness of the REST architectural style involving that each requests stands completely alone, leading server to never store any informations about client.

Thus, pessimistic concurrency control are not suitable because it would requires that server store which client gets the lock on a resource.
Optimistic concurrency control are then used, with the help of Etag header. (btw, as I asked there https://stackoverflow.com/questions/30080634/concurrency-in-a-rest-api)

Problem

The main problem with an optimistic concurrency control mechanism is that you allow all the time, all clients, to perform any operations.

And i would like to avoid that without breaking the statelessness principle of REST. I mean that all clients cannot perform any operation at any time.

Question

In my mind, it would possible with a semi-optimistic concurrency control mechanism, like that:

Clients can request a token
Only one token can be generated and has a limited period of validity
To perform operations on resources (such as POST or PUT), client must give this token as part of the body (or header?) of the request. Client that don't have the token cannot do these operations.

It is very similar to optimistic concurrency control, except that only one client can do some operations (the one that got the token)… at the opposite of "all clients can do all operations".

Does this mechanism is compatible with a REST architectural style ? Does it break any of its constraint ?
I was thinking to ask on SO, but this seems more an high-level question, related to software design.

Best Answer

You should never ( as in never ever EVER) lock any resource while waiting for a user interaction.

At some point some of your users will take off for a long weekend leaving some vital records locked.

Ah but you won't let that happen because you have some clever time out/deadlock resolution scheme; then at some point this will go horribly wrong and a user who got a nice "your widget has been ordered" message will be screaming at the help desk demanding to know why his widget was not delivered.

Most people can deal with "sorry another user has just ordered this part" message.

Related Solutions

REST Service Authentication/Authorization

If you are looking for ideas about security for REST web services then look at the OpenAuth spec Appendices describing the "handshake".

http://oauth.net/core/1.0/#anchor27

Creating web services that adhere to OpenAuth standards is probably one of the more secure ways that this can be done. It can give you ideas on authentication, authorization strategies.

The following is an example taken from the Authorization header in a GET or POST:

Authorization: OAuth
    oauth_consumer_key="xxxxxxxxxxxx",
    oauth_token="xxxxxxxxxxxx",
    oauth_nonce="xxxxxxxxxxxx",
    oauth_timestamp="1184242096",
    oauth_signature_method="HMAC-SHA1",
    oauth_version="1.0",
    oauth_signature="xxxxxxxxxxxxxxxxxx"

I am not going to go into all the details of OpenAuth but essentially it allows a client to provide a consumer key that identifies the client, a token that identifies the user, and a signature that represents the Base64 encoded bytes of the encrypted signature to verify that the request has not been tampered or altered on transport.

Building the signature string typically involves the percent encoded combination of the entire request, parameters, as well as consumer key, token, nonce, and a consumer secret which the client should keep safe. Once this signature string has been built and percent encoded it can then by encrypted, and those encrypted bytes can be constructed into a Base64 encoded string that is included in the Authorization header.

If you perform this over SSL, then this is undoubtedly one of the most secure ways to handle authentication/authorization of a REST based web service.

REST – Do Server-Side Sessions Violate REST Principles?

I would say yes, session state does make a RESTful app non-RESTful. Trivial example, my sister subscribes to the Wall Street Journal. On a regular basis she will be reading something behind the paywall and decide to send a link (via her own email client, not via WSJ) to a friend who does not have a WSJ account. Click, send, fail. Clearly my sister's experience at that URL is different from her friend's.

Related, but not strictly on-topic: I am in the early design phase of a application designed to support significant research efforts on the net (called quests (think: bookmarks on steroids and LSD)) . The owner of the quest wants to share a particular view of his/her data with someone else, but this view requires a combination of UI state (e.g. which visualizations of what data are showing in which panes) along with appropriate permissions to access the UI and the data displayed. There's a lot of stored-state required for the recipient to get the intended view.

My current solution is to store all of the UI/ACL/whatever info necessary for the view in a separate object and return the URL (probably a UUID) for that object. I believe that accessing the view object could be considered RESTful in the sense that everyone in possession of it gets the same info/experience.

Related Topic

HATEOAS REST Services – Strategies for Discovering REST Services Using HATEOAS