NAME
Whelk::Wrapper - Base class for wrappers
SYNOPSIS
package Whelk::Wrapper::MyWrapper;
use Kelp::Base 'Whelk::Wrapper';
# at the very least, there three methods must be implemented
sub wrap_server_error
{
my ($self, $error) = @_;
...;
}
sub wrap_success
{
my ($self, $data) = @_;
...;
}
sub build_response_schemas
{
my ($self, $endpoint) = @_;
...;
}
DESCRIPTION
Whelk::Wrapper is a base class for wrappers. Wrapper's job is to wrap the endpoint handler in necessary logic: validating request and response data, adding extra data to responses and error handling. Wrappers do not handle encoding requests and responses (for example with JSON
), that's a job for Whelk::Formatter.
In addition, wrapper decides how to treat failures. It defines schemas for errors with status classes 400 and 500 and uses those instead of response schema defined for the endpoint in case an error occurs.
Whelk implements two basic wrappers which can be used out of the box: Whelk::Wrapper::Simple (the default) and Whelk::Wrapper::WithStatus. They are very similar and differ in how they wrap the response data - WithStatus
wrapper introduces an extra boolean status
field to every response.
It should be pretty easy to subclass a wrapper if needed. Take a look at the built in subclasses and at the code of this class to get the basic idea.
METHODS
The only wrapper method called from outside is wrap
. All the other methods are helpers which make it easier to adjust the behavior without rewriting it from scratch.
The base Whelk::Wrapper
class does not implement wrap_server_error
, wrap_success
and build_response_schemas
methods - they have to be implemented in a subclass.
wrap
my $wrapped_sub = $wrapper->wrap($sub);
Takes a reference to a subroutine and returns a reference to another subroutine. The returned subroutine is an outer code to be called by Kelp as route handler. It does all the Whelk-specific behavior and calls the inner subroutine to get the actual result of the API call.
wrap_response
my $response = $wrapper->wrap_response($response, $http_code);
This method is used to wrap $response
returned by Kelp route handler. The default implementation takes a look at the $http_code
and fires one of wrap_success
(for codes 2XX), wrap_server_error
(for codes 5XX) or wrap_client_error
(for codes 4XX). The wrapped response must be matching the respone schema defined in "build_response_schemas" or else an exception will be thrown.
build_response_schemas
$wrapper->build_response_schemas($endpoint)
Takes an object of Whelk::Endpoint class and should set response_schemas
field of that object. That field must contain a hash reference where each key will be response code and each value will be a schema built using "build" in Whelk::Schema. Regular success schema should nest the value of $endpoint->response
schema inside of it.
The status codes need not to be exact. By default, only their class is important (200
, 400
or 500
). The exact semantics of that mapping is defined in another method, "map_code_to_schema".
If the schema from $endpoint->response
is empty via $endpoint->response->empty
then it must be added to response_schemas
as is to correctly be mapped to 204 No Body
HTTP status.
inhale_request
This is a helper method which validates the request. It may be overridden for extra behavior.
To ensure request_body
method works, it must set $app->req->stash->{request}
after validating and cleaning the request body.
execute
This is a helper method which runs the actual route handler in a try/catch block. It may be overridden for extra behavior.
prepare_response
This is a helper method which prepares a response to be passed to "exhale_response". It may be overridden for extra behavior.
exhale_response
This is a helper method which validates and returns a response. It may be overridden for extra behavior.
map_code_to_schema
This is a helper method which decides which key from response_schemas
of the endpoint to use based on HTTP code of the response. It may be overridden for extra behavior.
on_error
This is a helper method which decides what to do when an unexpected error occurs. By default, it creates an application log and modifies the result message to return a stock HTTP message like Internal Server Error
. It may be overridden for extra behavior.