Perl doesn't allow to change keys in place, you either need to copy to new a hash, or delete and recreate every single key to be transformed. If the hashes are nested you need to walk thru the tree.

If I were you I would just check if the JSON string has a pretty format which allows a simple regex to translate keys only.

update

proof of concept:

  DB<100> use JSON

  DB<101> $hoH = {
             nested => { crossReference => 42, incidentAbstract => "st
+ring" },
           }

  DB<102> $str = (new JSON)->pretty(1)->encode($hoH)
{
   "nested" : {
      "incidentAbstract" : "string",
      "crossReference" : "42"
   }
}

  DB<103> %translate= ( 
                      'crossReference' => 'cross_reference' ,
                      "incidentAbstract" => 'abstract',
                      )

  DB<104> $or_keys = join "|", keys %translate
 => "incidentAbstract|crossReference"

  DB<105> $str =~ s/^(\s+")($or_keys)("\s+:)/$1$translate{$2}$3/gm
 => 2

  DB<106> $str
{
   "nested" : {
      "abstract" : "string",
      "cross_reference" : "42"
   }
}
[download]

of course this can also be done with Data::Dumper ...

The data is nested. And I understand that keys can't be changed directly.

The suggestion of changing things in the JSON string, before decoding, is good and makes a lot of sense.

My primary concerns are that I had missed something, perhaps in the JSON modules, that could do this for me, or an existing other module to do the morphing, so I didn't need to write my own.

Thanks for the suggestion.

Hash::Map has several options to do what you are asking for.

If this is a one-time problem, though, I would just use Data::Dumper to dump the hash to a text file, then make the changes with a text editor.

For arbitrary depth structure you could use (untested)

use Data::Visitor::Callback;
my $v = Data::Visitor::Callback->new(
    ignore_return_values => 1,
    hash => sub {
        my %map = ( qw/ abeLincoln lincoln / );
        my $ref = $_; ##!!!
        my %new ;
        for my $key ( %{$ref} ){
            my $fkey = $map{$_} ;
            $new{ defined $fkey ? $fkey : $key } = $ref->{$key};
        }
        %{$ref} = %new;
    },
);
$v->visit();
[download]

I would simply define a package that “represents” the RESTful interface to the rest of the system(s), and, within that package, define a hash that maps old-names to new ones:

  my $FIELD_MAP = {
    // LIST ALL SERVER-SUPPLIED FIELDS EVEN IF NAME DOESN'T CHANGE
    // SERVER'S NAME ... => OUR NAME
    'incidentAbstract'   => 'abstract',
    'cross_reference'    => 'crossReference,
    ...
    };
[download]

Then, simply iterate through the keys in this map to populate a new hash that has the preferred field-names in it.   (Since both hashes contain references to the data in most cases, there probably won’t be too-much data actually moving around in memory as you do this.)

(Notice the comment that I made in the code-block.   $FIELD_MAP is supposed to define every field-name that this program expects to deal with in the data, and I think that your code should die if it ever encounters a field-name that is not.   I think that code should never be “trustful,” especially of remote systems.   (Data-providers and data-consumers have bugs in their code all the time, just like we all do, so don’t let ’em grind you down...)

This approach will have a number of advantages:   it will encapsulate the interface on behalf of the rest of the system or systems, and it will provide a consistent (and well-documented in the code ...) naming convention that remains the same as before.   (If you have a number of inconsistent systems on your side, subclassing could be used to good effect.)   The package is also suspicious of its host, therefore trustworthy:   if it runs to completion, it must be doing the right thing.