Rest Design concerning user login

Question

To be as restful as possible, is a user login better designed using a GET or a POST on a REST webservice? And why?

Answer 1

GET method should be used to obtain a representation of a resource. PUT - to update or replace an existing resource. Therefore, to perform the login action, POST is better.

Answer 2

I would use a POST, since it makes serious changes to the state of the server (even if not saved into the database). Though that's more a HTTP rule than REST.

Answer 3

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 notice.

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.