Assuming you already know about the different HTTP Methods you may agree with me that GET was the most appropriate method to use for logging in because a person was trying to GET their user information. The problem with that is GET is never appropriate for sensitive data like passwords. It can be logged in server logs and it can even be passed with the HTTP_Referrer heading. I’ve had discussions at length about whether we should use the “correct” method or be more secure. Usually being more secure won and we would do our user logins with POST.
It wasn’t until recently I’ve decided there’s a better way to do it! My whole paradigm when coming up with a apis for logging in was based on using a “users” api. I started to notice disconnect in my ideals with what I now consider the right way to do it. My first clue was the data I wanted returned. When I logged in I wanted different data than the data I got when retrieving another user’s information. This got me thinking that maybe user login should be a different api. But I wasn’t happy creating a user-login api since logging in is an action and not a resource. It finally struck me, (granted I’m sure smarter people out there figured this out first) create a user session api!
User Session Api
Using a user session api instead of a user api solves many of the problems I was having before. When we POST to the user session api to login we are creating a new user session and that makes sense! POSTing to the user api to login doesn’t make sense because we’re not creating a new user we’re logging in with an existing user.
When we want to verify our session we can use GET on the user session api to get our current session. And finally when we want to log out we can DELETE our user session.
I hope this epiphany has helped you. If you want more clarification or anything feel free to comment and I’ll try and update this post. Thanks!