Stateless means that HTTP doesn't have built in support for states; e.g. you can't store if a user has logged in or done something else.
The most common solution is to use sessions to overcome that problem. This means that you have to be able to include a session identifier in each response or request. This is either done by creating a session cookie or by including the session identifier in all links.
WebForms tries to make all that transparent (using ViewState) while MVC forces you to handle it manually.
In your example you mentioned Buttons and TextBoxes. The easiest way to let them maintaining their state is simply to stop posting back the entire page. MVC got excellent support for ajax (through jQuery) and I suggest that you use ajax if you just want to do something on the current page.
First of all, let me say that I agree 100% with @MvdD, that a REST API should not include login/logout semantics. However, as I'm sure you've heard/read OAuth is a headache you really don't want if you aren't "required" to have federated auth!
As other answers have pointed out, there is no one pattern to accomplish this, with several being accepted as answers in previous similar questions (mostly from SO). I'm also assuming you've looked at previous related questions and such. There is also this question (RESTful Authentication) on SO, which details 4 techniques (some more RESTful than others). If you're (seemingly?) happy to transmit the password as cleartext in HTTPS then option #1 of that answer (HTTP basic auth) would work with pretty much any HTTP library your REST tools are wrapping.
If you must...
Since there's a bounty and all (and because it's an interesting challenge), I thought about it, and (after about 1.5 cups of coffee) have had the following idea:
POST to a "challenge" resource, which then redirects to a resource identifier for that challenge, (and no this is not idempotent).
What am I talking about?
Well, as pointed out here (Table 1, page 3), resource identifiers are different to resources themselves. Ergo, you can RESTful-ly POST to one URI but be causing a change (i.e. RESTful change, such as CREATE, UPDATE) in a resource not necessarily located there. Let me explain in action...
Authentication Process:
- Client sends
POST /challenges with payload of username. This triggers the server to create necessary backend entry in DB table, allocate resources, etc.
- Server responds with a
303 See Other (which is just a newer version of 302 Moved temporarily), directing client to /challenges/<some random request code>.
- Client
GET's /challenges/<some random request code> (Note, will be GET, as 303 is used instead of 302). Which returns (with a 200 OK) a JSON-encoded challenge (more on this later).
- Client responds to challenge, this time with
POST to /challenges/<some random request code> with a hash meeting the challenge as payload.
- Server responds with either
403 Forbidden (if challenge failed, ergo, wrong password, etc) or a 200 OK (optionally with a JSON payload containing your session info or user profile or what-have-you).
A word on Challenges: (As promised in step #3)
The challenge given by the server is basically just some task (usually hashing, but possibly a two-way encryption/decryption, etc) given by the server to the client. The server knows (computes) the result (hence why hashes are good, since they're cheap) ahead of time, and compares that with the challenge-responce given by the client.
This can be as simple as some random text (or even static text, like your application name, etc) sent to the client in plaintext (or hash, not important) with the server having worked out the hash of that text (essentially a salt) concatenated with the (hashed, since it's in the DB - and we don't store plaintext passwords in databases) password.
If the client can concatenate this salt with the password (after hashing the password locally) and then hash that concatenation, it can answer the challenge.
Example:
- server: salt = md5("MaryHadALittleLamb") ->
8c20828418ca489f5b949f25f35abaa0 (sends to client in step #3).
- client: hashes the password "
password" ('username' is a notoriously insecure password selector) to produce 5f4dcc3b5aa765d61d8327deb882cf99, this is then concatenated with 8c20828418ca489f5b949f25f35abaa0 to produce "5f4dcc3b5aa765d61d8327deb882cf998c20828418ca489f5b949f25f35abaa0".
- client: hashes this
md5("5f4dcc3b5aa765d61d8327deb882cf998c20828418ca489f5b949f25f35abaa0") -> 09f3bb66a44153c4053857d4b57fdf3b and sends to server (step #4).
- server: (having already done the above itself) compares
09f3bb66a44153c4053857d4b57fdf3b with it's own result, and (if they match) allows username to login (or begin a session, etc).
Note: This is a fairly naive way to implement challenges, as there's no temporal component of the salt it's vulnerable to replay attacks, etc. But you can ask more about that on Security.SO if need be.
Best Answer
"web applications should be stateless" should be understood as "web applications should be stateless unless there is a very good reason to have state". A "shopping cart" is a stateful feature by design, and denying that is quite counter-productive. The whole point of the shopping cart pattern is to preserve the state of the application between requests.
An alternative which I could imagine as a stateless website which implements a shopping cart would be a single-page-application which keeps the shopping cart completely client-sided, retrieves product information with AJAX calls and then sends it to the server all at once when the user does a checkout. But I doubt I have ever seen someone actually do that, because it doesn't allow the user to use multiple browser tabs and doesn't preserve state when they accidentally close the tab. Sure, there are workarounds like using localstorage, but then you do have state again, just on the client instead of on the server.
Whenever you have a web application which requires to persist data between pageviews, you usually do that by introducing sessions. The session a request belongs to can be identified by either a cookie or by a URL parameter you add to every link. Cookies should be preferred because they keep your URLs more handy and prevent your user from accidentally sharing an URL with their session-id in it. But having URL tokens as a fallback is also vital for users which deactivate cookies. Most web development frameworks have a session handling system which can do this out-of-the-box.
On the server-side, session information is usually stored in a database. Server-side in-memory caching is optional. It can greatly improve response time, but won't allow you to transfer sessions between different servers. So you will need a persistent database as a fallback.
Do they allow you to log in? When you then close the tab and revisit the site, are you still logged in? If you are, then they are using cookies to preserve your identity between sessions.