Any verbs (besides OPTIONS which is automatic) which are not specifically defined as a class method will generate a 405
error.

If you'd like to specify the error library that will be used to create the 405 error (which may affect instanceof
checks elsewhere in your application code) you can pass in the option errors to the .handler() static method.

MyView.handler({
errors:require('http-errors')
});

The only requirements for this option:

Needs to be a function.

Should accept an integer as the first argument to specify which error gets created.

Overriding OPTIONS

The OPTIONS verb will be handled by default and will send a simple Accepts header including all the verbs specified on
your view class. You can easily override this behavior by specifying a class method for the OPTIONS verb.

Whenever you call the class method .handler() an instance of your view class is created. For every method handler the
context this will be the instance of your view. So any variables you add in the constructor will be available there.

What's Left

There are still some pain points that may be addressed in future versions.

For instance it's still cumbersome to prepend your class views with middleware to handle behaviors. Let's say you wanted
to check that a request is logged in with some middleware function loginRequred on all verbs and validate CSRF tokens
with another middleware function csrfValidate on POST and PUT.