Restful Account Activation
Nearly every web application has the concept of users or accounts. While the concept of a user or account is quite universal, when you get to implementing, you find out that the business rules and implementation details vary widely from application to application. Luckily for your Ruby on Rails applications, there's an excellent starting point for creating the basics of accounts and logins. The restful_authentication plugin for Rails provides generators for Users and the basic framework required, such as email activations, logins, passwords, controllers, and database migrations. The extra bonus is that the plugin uses REST to model the authentication.
In the REST web application world, all you see are objects, or nouns. The verbs in the system are limited to the HTTP methods such as GET, PUT, POST, and DELETE. REST advocates that you interact with the world (your nouns) with these four methods. It forces you to think, "How would I convert an Action into a Thing?"
With restful_authentication, the action is Login, but that concept is encapsulated into a Session object. When you login, you are *creating* a new Session. When you logout, you are *deleting* that Session. (Here, the Session is a different concept from a web session.) The plugin nicely models login and logout actions into CREATE Session and DELETE Session.
We can apply this concept to account activation, which I had to do recently for one of our applications. Our business rules stated that an account can't access the system until it was activated by an administrator.
In the old pre-REST days, we might have modeled this with an action called activate, which might have set an activated bit on the account instance. Fair enough, and it would have worked fine. But this isn't RESTful at all, as it would require a new verb in the system (activate).
Knowing that REST is all about the nouns, we noun-ify the concept of activation into a class called Activation. We say that an Account has one Activation, and if that activation relationship exists, the account is activated. If there is no activation instance for an account, then the account is deactivated. An administrator will CREATE an activation instance in order to activate an account. The administrator can later on DELETE the activation instance if they want to deactivate the account.
Another benefit of creating a first class Activation model is we can add properties such as when the account was activated and who activated it.
In summary, I love working with REST because it forces me to think in nouns, which are classes. I find it easier to model the world with nouns than with verbs. Plus, the problem with verbs is you can't say anything about them, so you lose the ability to add metadata to the events in the system.
In the REST web application world, all you see are objects, or nouns. The verbs in the system are limited to the HTTP methods such as GET, PUT, POST, and DELETE. REST advocates that you interact with the world (your nouns) with these four methods. It forces you to think, "How would I convert an Action into a Thing?"
With restful_authentication, the action is Login, but that concept is encapsulated into a Session object. When you login, you are *creating* a new Session. When you logout, you are *deleting* that Session. (Here, the Session is a different concept from a web session.) The plugin nicely models login and logout actions into CREATE Session and DELETE Session.
We can apply this concept to account activation, which I had to do recently for one of our applications. Our business rules stated that an account can't access the system until it was activated by an administrator.
In the old pre-REST days, we might have modeled this with an action called activate, which might have set an activated bit on the account instance. Fair enough, and it would have worked fine. But this isn't RESTful at all, as it would require a new verb in the system (activate).
Knowing that REST is all about the nouns, we noun-ify the concept of activation into a class called Activation. We say that an Account has one Activation, and if that activation relationship exists, the account is activated. If there is no activation instance for an account, then the account is deactivated. An administrator will CREATE an activation instance in order to activate an account. The administrator can later on DELETE the activation instance if they want to deactivate the account.
Another benefit of creating a first class Activation model is we can add properties such as when the account was activated and who activated it.
In summary, I love working with REST because it forces me to think in nouns, which are classes. I find it easier to model the world with nouns than with verbs. Plus, the problem with verbs is you can't say anything about them, so you lose the ability to add metadata to the events in the system.