Is connection pooling possible with REST?

Question

Since REST is stateless, each request that comes in has no knowledge of the previous request that comes in. Is connection pooling possible in this situation?

If connection pooling were to be implemented, it would open the connection pool and close it upon each request just like a standard database connection.

How can REST be implemented to take advantage of connection pooling?

Answer 1

You need to understand what is connection pooling (object pool), caching and difference.

Connection pools are created to avoid the expense of creating these expensive resources. They are mostly created and stored somewhere and after being used, they return back to pool and can be used again. this was you avoid the expense of creating these resources over and over. such as database connections.

for REST, how do you make a request to a REST service? lets say over HTTP via PUT,GET, POST etc. so you need HTTP connection. if you are worried about the server, depending on the server you are using, most of them uses threads.

I have a feeling, you might be confused with caching and object pooling. with object pool, just like a thread pool, you create X amount of that object and store it in a pool (usually queue). Whenever you need one, you ask one from the pool. after you are done with it you return it to the pool.

REST in connection pool context make too much sense.

What you might want is caching... REST is stateless but each object has a unique identifier, so you can cache it based on that ID.

Answer 2

it certainly would be possible: REST doesn't dictate anything with regards to how your server is built internally but for ignoring state and having a uniform HTTP interface. You could thus have a server process that uses a connection-pool for connecting to your database but that still is perfectly in line with the whole REST, stateless, drop-in component style of design.