Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
Related:… – Mike Partridge Nov 27 '12 at 15:56
up vote 3 down vote accepted

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.

share|improve this answer
POST is to create new resource, isn't it? – Pierre Nov 28 '12 at 14:27
Yes. I think the login action might be considered as creation of a new resource because it (usually) creates a new user session. – evfwcqcg Nov 28 '12 at 16:18

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.

share|improve this answer
So why not PUT? As we are updating existing account, if there are anything to be changed. – Ck- Nov 27 '12 at 13:44
I guess PUT could be used too or may be even more correct in some cases. PUT requests should be idempotent and sending the same thing twice should result in the same state on the server. If your system accepts multiple requests and just lets the user logged in, PUT would be ok (even if the response is something like "already logged in"). – thorsten müller Nov 27 '12 at 13:50

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.