This article at InfoQ has helped with my understanding of REST. Paraphrasing from the Use standard methods section:
PUT means, essentially: "update this resource with this data, or
create it at this URI if it’s not there already", whereas POST means
"create a new resource."
According to IBM DeveloperWorks though:
- To create a resource on the server, use POST.
- To change the state of a resource or to update it, use PUT.
Based on these definitions, if you plan to continually update some kind of access token to indicate that a user is still logged in, use POST to create it, then PUT to update it on subsequent requests.
Also, from the Communicate statelessly section:
REST mandates that state be either turned into resource state, or kept
on the client. In other words, a server should not have to retain some
sort of communication state for any of the clients it communicates
with beyond a single request. The most obvious reason for this is
scalability — the number of clients interacting would seriously impact
the server’s footprint if it had to keep client state. (Note that this
usually requires some re-design — you can’t simply stick a URI to some
session state and call it RESTful.)
But there are other aspects that might be much more important: The
statelessness constraint isolates the client against changes on the
server as it is not dependent on talking to the same server in two
consecutive requests. A client could receive a document containing
links from the server, and while it does some processing, the server
could be shut down, its hard disk could be ripped out and be replaced,
the software could be updated and restarted — and if the client
follows one of the links it has received from the server, it won’t
Given that, it seems like we shouldn't be creating any server state to track what users are logged in; rather we should perhaps be using HTTP Authentication.
Here's another good question related to the issue of authentication for REST services.