view release on metacpan or  search on metacpan

lib/Dancer2/Serializer/Mutable.pm  view on Meta::CPAN

    # in config.yml
    serializer: Mutable

    engines:
        serializer:
            Mutable:
                mapping:
                    'text/x-yaml'        : YAML
                    'text/html'          : YAML
                    'text/x-json'        : JSON
                    'application/json'   : JSON

    # in the app
    put '/something' => sub {
        # deserialized from request
        my $name = param( 'name' );

        ...

        # will be serialized to the most
        # fitting format
        return { message => "user $name added" };
    };

=head1 DESCRIPTION

This serializer will try find the best (de)serializer for a given request.
For this, it will pick the first valid content type found from a list, and
use its related serializer. The list, and its order, is not the same in both
directions:

=over

=item

When B<deserializing> an incoming request body (that is, working out how to
read it), the order is: the B<content_type> from the request headers, then
the B<accept> from the request headers, then the default of
B<application/json>.

=item

When B<serializing> a response (that is, working out what to send back), the
order is: the B<accept> from the request headers, then the B<content_type>
from the request headers, then the default of B<application/json>. Consulting
C<Accept> first is deliberate - it is the header a client uses to say what it
wants back, which need not match the content type of what it sent.

=back

In both directions, a header's value is matched against the mapping on its
content type alone: any C<;>-separated parameters (such as
C<; charset=utf-8>) are stripped, surrounding whitespace is trimmed, and the
result is lowercased before comparison. So C<Content-Type: text/x-yaml>,
C<Content-Type: text/x-yaml; charset=utf-8> and C<Content-Type: TEXT/X-YAML>
are all recognised as C<text/x-yaml>. An C<Accept> header listing several
comma-separated types is not split further - it is matched as a whole after
parameter-stripping, so only a single-type C<Accept> value is recognised;
anything else falls through to the next header or the default.

The content-type/serializer mapping that C<Dancer2::Serializer::Mutable>
uses is

    serializer                  | content types
    ----------------------------------------------------------
    Dancer2::Serializer::YAML   | text/x-yaml, text/html
    Dancer2::Serializer::JSON   | text/x-json, application/json

The keys above are bare, lowercase content types - not raw header values - as
described above.

A different mapping can be provided via the config file. For example,
the default mapping would be configured as

    engines:
        serializer:
            Mutable:
                mapping:
                    'text/x-yaml'        : YAML
                    'text/html'          : YAML
                    'text/x-json'        : JSON
                    'application/json'   : JSON

The values are the serializers to use. Serialization for C<YAML> and C<JSON>
are done using internal Dancer mechanisms. Any other serializer will be taken
to be a Dancer2 serialization class (minus the C<Dancer2::Serializer::>
prefix) and an instance of it will be used to serialize/deserialize data.
For example, adding L<Dancer2::Serializer::XML> to the mapping would be:

    engines:
        serializer:
            Mutable:
                mapping:
                    'text/x-yaml'        : YAML
                    'text/html'          : YAML
                    'text/x-json'        : JSON
                    'text/xml'           : XML

=head2 Dumper

The Dumper serializer is B<not> available by default, as it deserializes
request content by evaluating it as Perl code, which is insecure and a bad
idea. If you really want to use it, you must explicitly opt in, and you must
have the C<Dancer2-Serializer-Dumper> distribution installed. You can then
enable it either by adding it to your mapping and setting
C<enable_dumper>:

    engines:
        serializer:
            Mutable:
                enable_dumper: 1
                mapping:
                    'text/x-yaml'        : YAML
                    'text/html'          : YAML
                    'text/x-data-dumper' : Dumper
                    'text/x-json'        : JSON
                    'application/json'   : JSON

or by using the default mapping with C<enable_dumper> set, which adds
C<text/x-data-dumper> to the default mapping:

    engines:
        serializer:
            Mutable:
                enable_dumper: 1

Attempting to use the Dumper serializer without setting C<enable_dumper>
to a true value will cause a fatal error.

=head2 INTERNAL METHODS

The following methods are used internally by C<Dancer2> and are not made
accessible via the DSL.

=head2 serialize

Serialize a data structure. The format it is serialized to is determined
automatically as described above. It can be one of YAML, JSON, defaulting
to JSON if there's no clear preference from the request.

=head2 deserialize

Deserialize the provided serialized data to a data structure.  The type of
serialization format depends on the request's content-type. For now, it can
be one of YAML, JSON.

=head2 content_type

Returns the content-type that was used during the last C<serialize> /
C<deserialize> call. B<WARNING> : you must call C<serialize> / C<deserialize>
before calling C<content_type>. Otherwise the return value will be C<undef>.

=head1 AUTHOR

Dancer Core Developers

=head1 COPYRIGHT AND LICENSE

This software is copyright (c) 2026 by Alexis Sukrieh.

This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.

=cut