The controller receives a request from a user, passes incoming data to the model and retrieves data from it, which then gets turned into an actual response by the view. But note that this pattern is just a guideline that most of the time results in cleaner more maintainable code, not a rule that should be followed at all costs.

REST is a software architectural style for distributed hypermedia systems such as the web. While it can be applied to many protocols it is most commonly used with HTTP these days. In REST terms, when you are opening a URL like http://mojolicious.org/foo with your browser, you are basically asking the web server for the HTML representation of the http://mojolicious.org/fooresource.

The fundamental idea here is that all resources are uniquely addressable with URLs and every resource can have different representations such as HTML, RSS or JSON. User interface concerns are separated from data storage concerns and all session state is kept client-side.

Traditionally all session data was stored on the server-side and only session ids were exchanged between browser and web server in the form of cookies.

Set-Cookie: session=hmac-sha1(base64(json($session)))

In Mojolicious however we are taking this concept one step further by storing everything JSON serialized and Base64 encoded in HMAC-SHA1 signed cookies, which is more compatible with the REST philosophy and reduces infrastructure requirements.

TDD is a software development process where the developer starts writing failing test cases that define the desired functionality and then moves on to producing code that passes these tests. There are many advantages such as always having good test coverage and code being designed for testability, which will in turn often prevent future changes from breaking old code. Much of Mojolicious was developed using TDD.

In Mojolicious we consider web applications simple frontends for existing business logic, that means Mojolicious is by design entirely model layer agnostic and you just use whatever Perl modules you like most.

Our login manager will simply use a plain old Perl module abstracting away all logic related to matching usernames and passwords. The name MyApp::Model::Users is an arbitrary choice, and is simply used to make the separation of concerns more visible.

The startup method gets called right after instantiation and is the place where the whole application gets set up. Since full Mojolicious applications can use nested routes they have no need for group blocks.