package Catalyst::TraitFor::Request::REST;
$Catalyst::TraitFor::Request::REST::VERSION = '1.21';
use Moose::Role;
use HTTP::Headers::Util qw(split_header_words);
use namespace::autoclean;

has [qw/ data accept_only /] => ( is => 'rw' );

has accepted_content_types => (
    is       => 'ro',
    isa      => 'ArrayRef',
    lazy     => 1,
    builder  => '_build_accepted_content_types',
    clearer  => 'clear_accepted_cache',
    init_arg => undef,

has preferred_content_type => (
    is       => 'ro',
    isa      => 'Str',
    lazy     => 1,
    builder  => '_build_preferred_content_type',
    init_arg => undef,

# By default the module looks at both Content-Type and
# Accept and uses the selected content type for both
# deserializing received data and serializing the response.
# However according to RFC 7231, Content-Type should be
# used to specify the payload type of the data sent by
# the requester and Accept should be used to negotiate
# the content type the requester would like back from
# the server. Compliance mode adds support so the method
# described in the RFC is more closely model.
# Using a bitmask to represent the the two content type
# header schemes.
# 0x1 for Accept
# 0x2 for Content-Type

has 'compliance_mode' => (
    is       => 'ro',
    isa      => 'Int',
    lazy     => 1,
    writer   => '_set_compliance_mode',
    default  => 0x3,

# Set request object to only use the Accept header when building
# accepted_content_types
sub set_accept_only {
    my $self = shift;

    # Clear the accepted_content_types cache if we've changed
    # allowed headers

# Set request object to only use the Content-Type header when building
# accepted_content_types
sub set_content_type_only {
    my $self = shift;


# Clear serialize/deserialize compliance mode, allow all headers
# in both situations
sub clear_compliance_mode {
    my $self = shift;


# Return true if bit set to examine Accept header
sub accept_allowed {
    my $self = shift;

    return $self->compliance_mode & 0x1;

# Return true if bit set to examine Content-Type header
sub content_type_allowed {
    my $self = shift;

    return $self->compliance_mode & 0x2;

# Private writer to set if we're looking at Accept or Content-Type headers
sub _set_compliance_mode {
    my $self = shift;
    my $mode_bits = shift;


sub _build_accepted_content_types {
    my $self = shift;

    my %types;

    # First, we use the content type in the HTTP Request.  It wins all.
    # But only examine it if we're not in compliance mode or if we're
    # in deserializing mode
    $types{ $self->content_type } = 3
        if $self->content_type && $self->content_type_allowed();

    # Seems backwards, but users are used to adding &content-type= to the uri to
    # define what content type they want to recieve back, in the equivalent Accept
    # header. Let the users do what they're used to, it's outside the RFC
    # specifications anyhow.
    if ($self->method eq "GET" && $self->param('content-type') && $self->accept_allowed()) {
        $types{ $self->param('content-type') } = 2;

    # Third, we parse the Accept header, and see if the client
    # takes a format we understand.
    # But only examine it if we're not in compliance mode or if we're
    # in serializing mode
    # This is taken from chansen's Apache2::UploadProgress.
    if ( $self->header('Accept') && $self->accept_allowed() ) {
        $self->accept_only(1) unless keys %types;

        my $accept_header = $self->header('Accept');
        my $counter       = 0;

        foreach my $pair ( split_header_words($accept_header) ) {
            my ( $type, $qvalue ) = @{$pair}[ 0, 3 ];
            next if $types{$type};

            # cope with invalid (missing required q parameter) header like:
            # application/json; charset="utf-8"
            unless ( defined $pair->[2] && lc $pair->[2] eq 'q' ) {
                $qvalue = undef;

            unless ( defined $qvalue ) {
                $qvalue = 1 - ( ++$counter / 1000 );

            $types{$type} = sprintf( '%.3f', $qvalue );

    [ sort { $types{$b} <=> $types{$a} } keys %types ];

sub _build_preferred_content_type { $_[0]->accepted_content_types->[0] }

sub accepts {
    my $self = shift;
    my $type = shift;

    return grep { $_ eq $type } @{ $self->accepted_content_types };


=head1 NAME

Catalyst::TraitFor::Request::REST - A role to apply to Catalyst::Request giving it REST methods and attributes.


     if ( $c->request->accepts('application/json') ) {

     my $types = $c->request->accepted_content_types();


This is a L<Moose::Role> applied to L<Catalyst::Request> that adds a few
methods to the request object to facilitate writing REST-y code.
Currently, these methods are all related to the content types accepted by
the client and the content type sent in the request.

=head1 METHODS


=item data

If the request went through the Deserializer action, this method will
return the deserialized data structure.

=item accepted_content_types

Returns an array reference of content types accepted by the

The list of types is created by looking at the following sources:

=over 8

=item * Content-type header

If this exists, this will always be the first type in the list.

=item * content-type parameter

If the request is a GET request and there is a "content-type"
parameter in the query string, this will come before any types in the
Accept header.

=item * Accept header

This will be parsed and the types found will be ordered by the
relative quality specified for each type.


If a type appears in more than one of these places, it is ordered based on
where it is first found.

=item preferred_content_type

This returns the first content type found. It is shorthand for:


=item accepts($type)

Given a content type, this returns true if the type is accepted.

Note that this does not do any wildcard expansion of types.


=head1 AUTHORS

See L<Catalyst::Action::REST> for authors.

=head1 LICENSE

You may distribute this code under the same terms as Perl itself.