Provided by: libcatalyst-action-rest-perl_1.21-1_all bug


       Catalyst::Action::Deserialize - Deserialize Data in a Request


           package Foo::Controller::Bar;

               'default'   => 'text/x-yaml',
               'stash_key' => 'rest',
               'map'       => {
                   'text/x-yaml'        => 'YAML',
                   'text/x-data-dumper' => [ 'Data::Serializer', 'Data::Dumper' ],

           sub begin :ActionClass('Deserialize') {}


       This action will deserialize HTTP POST, PUT, OPTIONS and DELETE requests.  It assumes that
       the body of the HTTP Request is a serialized object.  The serializer is selected by
       introspecting the requests content-type header.

       If you want deserialize any other HTTP method besides POST, PUT, OPTIONS and DELETE you
       can do this by setting the "deserialize_http_methods" list via "action_args".  Just modify
       the config in your controller and define a list of HTTP methods the deserialization should
       happen for:

               action_args => {
                   '*' => {
                       deserialize_http_methods => [qw(POST PUT OPTIONS DELETE GET)]

       See also "action_args" in Catalyst::Controller.

       The specifics of deserializing each content-type is implemented as a plugin to
       Catalyst::Action::Deserialize.  You can see a list of currently implemented plugins in

       The results of your Deserializing will wind up in $c->req->data.  This is done through the
       magic of Catalyst::Request::REST.

       While it is common for this Action to be called globally as a "begin" method, there is
       nothing stopping you from using it on a single routine:

          sub foo :Local :Action('Deserialize') {}

       Will work just fine.

       When you use this module, the request class will be changed to Catalyst::Request::REST.

RFC 7231 Compliance Mode

       To maintain backwards compatibility with the module's original functionality, where it was
       assumed the deserialize and serialize content types are the same, an optional compliance
       mode can be enabled to break this assumption.

               'compliance_mode'    => 1,
               'default'            => 'text/x-yaml',
               'stash_key'          => 'rest',
               'map'                => {
                   'text/x-yaml'        => 'YAML',
                   'text/x-data-dumper' => [ 'Data::Serializer', 'Data::Dumper' ],
               'deserialize_default => 'application/json',
               'deserialize_map'    => {
                   'application/json'   => 'JSON',

       Three extra keys are added to the controller configuration. compliance_mode, a boolean to
       enable the mode. And a parallel set of content type mappings 'deserialize_default' and
       'deserialize_map' to mirror the default/map configuration keys.

       The module will use the default/map keys when negotiating the serializing content type
       specified by the client in the Accept header. And will use the
       deserialize_default/deserialize_map in conjunction with the Content-Type header where the
       client is giving the content type being sent in the request.


       For building custom error responses when de-serialization fails, you can create an
       ActionRole (and use Catalyst::Controller::ActionRole to apply it to the "begin" action)
       which overrides "unsupported_media_type" and/or "serialize_bad_request" methods.


       You likely want to look at Catalyst::Controller::REST, which implements a sensible set of
       defaults for a controller doing REST.

       Catalyst::Action::Serialize, Catalyst::Action::REST


       See Catalyst::Action::REST for authors.


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