RESTful Logins

If you are constructing a web application, you will probably have to create a login page that generates a user session. If you are not aware, RESTful (representational state transfer) URLs are considered best practice for internet applications. As a general rule (only to be broken under duress), RESTful URLs should be nouns, while the HTTP method is the verb. For example, if you want to see a user profile page and the user ID is 8, then a RESTful URL would be https://host/users/8/. “users” is a noun, and the HTTP method you would use is GET. An outdated, RPC-like (remote procedure call) URL might be https://host/GetUser/?id=8. “GetUser” is a sentence and not a noun, and so is not a resource and should not be referred to by a URL (uniform resource locator).

So how do you resist the temptation to make a URL like https://host/login/, since “login” a verb and not a noun?

Consider what is happening when you login to a web application. What resource is being accessed, created, or modified?

The session!

So when making a login page, use URLs and HTTP methods as follows:

• GET https://host/session/ retrieves a login page with a username and password form
• POST https://host/session/ submits your credentials
• DELETE https://host/session/ logs you out

DELETE is not available via HTML forms, so you’ll have to use AJAX.

One last note: why use POST to create the session rather than PUT, such as PUT https://host/session/username/?

There are two reasons:

1. Your username will be unencrypted when querying a DNS for the IP address of the server.
2. PUT is idempotent, so if you log in from separate clients, the first session will be semantically overwritten, logging you out. This doesn't usually actually happen since the session is stored in a token on the client side, but relying on this fact is an abuse of HTTP semantics.

Learn more about DMC's web application development services.