Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How good and/or necessary are Stateful Web Services?

What kind of server do you people see in real projects?

1) Web Services MUST be stateless: Basically you must send username/password with every request, every request must use HTTPS and I will authenticate and load the User object everytime if needed.

2) A Session for Web Services: like in a web container so I can at least save the authenticated User object and have something similar to a session ID so I don't need to authenticate, load and check the User on every request.

3) Sticky Service (persistent service across requests): https://jax-ws.dev.java.net/nonav/2.1/docs/statefulWebservice.html

I understand the scalability problems of stateful services (and of web application sessions), but sometimes you must have some kind of state, for example for a shopping cart. But you can also put this state in the database (use the back-end as a kind of session argh) or passing the entire state to the client (the client becomes responsible for resending the entire shopping cart).

The truth is, at least for web applications, the session helps a lot in many situations. Scalability issues can be ignored if your system accepts that "the user must start over doing whatever he is doing if his web server happens to go down" or you can try a session cluster if that's unacceptable.

How it is for web services? I am inclined to conclude that web services are very different than web applications and accept option 1) (always stateless), but it would be nice to hear other opinions based on real project experience.

like image 781
TraderJoeChicago Avatar asked Jun 17 '09 22:06

TraderJoeChicago


People also ask

What is stateful web service?

Stateful Web Services Let's say you log into a resource, and in doing so, you pass your password and username. If the web server stores this data in a backend manner and uses it to identify you as a constantly connected client, the service is stateful.

Why should service be stateless?

These loosely-coupled, heterogeneous, and composite applications require that all Services should be stateless such that they don't impose their knowledge of a system or process unnecessarily on other parties, thus tightening their level of coupling, reducing their ability for reuse, and limiting broad applicability.

What is stateful web applications?

A stateful app is a program that saves client data from the activities of one session for use in the next session. The data that is saved is called the application's state.

What is the main difference between stateless and stateful servers?

Stateless Protocol is a network protocol in which Client send request to the server and server response back as per the given state. Stateful Protocol is a network protocol in which if client send a request to the server then it expects some kind of response, in case of no response then it resend the request.


1 Answers

While it's only a small difference but it should still be mentioned:

It's not state in web services that kill scalability, rather it's state on the App Server that's hosting the web services that will kill scalability. The moment you say that this user needs to access this server (as done in sticky sessions) you are effectively limiting your scalability options. The point you want to get to is that 'Any of your free load-balanced App servers' can handle this web service request and if I add 1 more App Server I should be able to handle % more users.

It's totally fine (and personally recommended) if you want to maintain state to pass in an authentication token and on each request get the service to retrieve your 'state' from a data store (preferably a redundant and partitioned one, e.g. distributed+replicated key/value data store). That's how Amazon does it with SimpleDb and Google with BigTable.

Ebay takes a slightly different approach and stores most of the clients state in a cookie so it gets passed in with every request. Although it generates a lot more traffic, it still scalable as any of their servers can still handle the request.

If you want a scalable data store I would recommend looking at redis it has speed and features that can't be beat in a key/value data store.

You should also check out highscalability.com if you want access to good material on how to build fast and scalable services.

like image 200
mythz Avatar answered Oct 29 '22 00:10

mythz