The RESTful API should be stateless, but what about concurrency?

Question

I am curious how I solve the concurrency problem for a RESTful API. More specifically, I have a set of objects that require manual verification and updating, for example. a series of rows that need a manually updated column; however, if I open the API for several clients, all of them will grab these elements from top to bottom, so many users will populate a column of the same row at the same time. I would prefer not to have collisions, and a simple, from the point of view of state, way is to simply drop the items into the service queue and push them when people ask for them.

What is a stateless version? Hashed by IP address or randomly grab strings based on identifier?

:: update ::

"Hrm, why should it just be stateless from a customer perspective?

This certainly makes a lot of sense. I just read an article (ibm.com/developerworks/webservices/library/ws-restful) about RESTful APIs and, faced with a bit of paging, I was worried that my well-to-do queue looked like a page increase, but they they are actually quite different, since the “next page” is relative on the client side, whereas “pop” always has no status for the client: it does not matter what came up before.

Thanks for cleaning my head! "-Me

Answer 1

There are two main approaches:

• Go completely stateless and adopt the "last call wins" strategy. Oddly enough, perhaps this is the cleanest solution in terms of predictability, scalability, code complexity, and client-server implementation. There are also many priorities: see how sites like Google paginate with start=10 for page 2, start=20 for page 3, etc.

  You may find that content changes inside pages as you move between them, but what? You always get the latest information, and Google can process your requests on any of its many servers without having to find session information to determine what your last request context is.

  The biggest advantage of this approach is the ease of implementation of your server. Each request can simply go to the data level on the internal server, and it is completely ripe for caching both at the HTTP level (via E-tags, and with the last changed headers) and on the server side (using something like memcache, for example) .

• Go into the "stateful" state and determine how your servers perform some kind of lock or token for each client for each API session. It will be like trying to fight the ocean tide with a stick because you will end your failure and disappointment.

  How will you identify customers? Session Keys? IP address? The file descriptor for the socket they entered into (good luck with this if you use a transport like HTTP where the connection may be closed between requests ...)? The details that you choose for this must be saved on the server side, or you will have to use some nasty old sticky session functions on your application server (and if so, heaven help your client if the server they use goes down the middle of the session )

  How will you handle API clients that disappear ruthlessly? Will you automatically block your session locks if the message flows were empty? This is more code, more complexity and more places to hide errors. What about API clients returning from long downtime and trying to reuse expired locks, how do you create client applications to handle this situation?

I could go on, but hopefully you can see my thought. Go with option 1 and go stateless. Otherwise, you will try to monitor the status of the client on the server side. And the only thing that should monitor the status of the client is the client himself.

Answer 2

It is normal to maintain the state of a resource. A "stateless ban" refers only to a session state.

Here is an excerpt from Roy Fielding, the fundamental conclusion of REST :

Then we add a restriction on client-server interaction: the connection must be stateless in nature, as in the client-stateless-server (CSS) style of section 3.4.3 (Figure 5-3), so that each request from the client to the server should contain everything information necessary for understanding the request, and cannot take advantage of any stored context on the server. Session state is therefore completely stored on the client.