Responses. For each HTTP request an application receives, an instance of
Requestis created. A
Responsemust be created for each request. Responses are created by controller objects. This guide discusses the behavior and initialization of controllers. You can read more about request and response objects here.
linkmethod. This method takes a closure that returns the next controller in the channel. The following shows a channel composed of two controllers:
ResponseController. A request handled by the verifying controller can either respond to the request or let the response controller handle it. If the verifying controller sends a respond, the response controller will never receive the request. Any number of controllers can be linked, but the last controller linked must respond to a request. Controllers that always respond to request are called endpoint controllers. Middleware controllers verify or modify the request, and typically only respond when an error is encountered.
handlemethod to handle a request. You override this method in your controllers to provide the logic for your controllers. The following is an example of an endpoint controller, because it always sends a response:
handlemethod returns a
Responseobject. Any time a controller returns a response, Conduit sends a response to the client and terminates the request so that no other controllers can handle it.
Authorizercontroller returns a
401 Unauthorizedresponse if the request's credentials are invalid. To let the request pass to the next controller, you must return the request object.
Authorizerlooks like this:
addResponseModifieron a request.
handlecan be linked to controllers:
Controller.handle: it can return a request or response, automatically handles exceptions, and can have controllers (and functions) linked to it.
linktakes a closure, instead of a controller object. Conduit is an object oriented framework. Objects have both state and behavior. An application will receive multiple requests that will be handled by the same type of controller. If a mutable controller object were reused to handle multiple requests, it could retain some of its state between requests. This would create problems that are difficult to debug.
linkclosure is invoked once to create and link the controller object, and then the closure is discarded. The same controller object will be reused for every request.
ResourceControllercan have properties that are bound to the values of a request, and therefore these properties will change and a new instance must be created for each request.
Controllersubclass must implement
linkclosure will be invoked for each request, creating a new instance of the recyclable controller to handle the request. If a controller has an expensive initialization process, the results of that initialization can be calculated once and reused for each controller instance by implementing the methods from
recycledStategetter is called once, when the controller is first linked. Each new instance of a recyclable controller has its
restoremethod invoked prior to handling the request, and the data returned by
recycledStateis passed as an argument. As an example,
ResourceController'compiles' its operation methods. The compiled product is stored as recycled state so that future instances can bind request data more efficiently.
Responsecan be thrown at any time; the controller handling the request will catch it and send it to the client. This completes the request. This might not seem useful, for example, the following shows a silly use of this behavior:
HandlerExceptionto provide a response other than the default when thrown. For example, an application that handles bank transactions might declare an exception for invalid withdrawals:
HandlerException. An implementor must provide an implementation for
Controllers have built-in behavior for handling CORS requests. They will automatically respond to
OPTIONSpreflight requests and attach CORS headers to any other response. See the chapter on CORS for more details.