NAME

Net::Dynect::REST::info - information about the Net::Dynect::REST modules

DESCRIPTION

The Net::Dynect::REST, Net::Dynect::REST::Request and Net::Dynect::REST::Response implemnt a basic framework for the sending and recieving of queries to Dynect. While you're free to use that, a more polished API exists to permit you to deal with objects. This more polished API is an implementation of the (majority of) the Dynect REST API.

The modules that can be used correspond to the documentation of the REST API:

• Net::Dynect::REST::AAAARecord - for IPv6 address resource records

• Net::Dynect::REST::ARecord - for IPv4 address records

• Net::Dynect::REST::CNAMERecord - for CNAME (alias) records

• Net::Dynect::REST::DNSKEYRecord - for public key that resolvers can use to verify DNSSEC

• Net::Dynect::REST::DSRecord - for the delegation signer for the zone

• Net::Dynect::REST::KEYRecord - the older record for public keys for DNSSEC

• Net::Dynect::REST::LOCRecord - The location of the recource - latitude, longditure, altitude (sometimes called the ICMB resource record)

• Net::Dynect::REST::MXRecord - The Mail Exchanger record

• Net::Dynect::REST::NSRecord - the Name Server record

• Net::Dynect::REST::SRVRecord - the Service record

• Net::Dynect::REST::TXTRecord - for TXT (text) records

In addition, the following classes exist:

• Net::Dynect::REST::ANYRecord - to retrieve all the objects that exist for a FQDN - eg, ARecords, AAAARecords, TXTRecords... in one hit

• Net::Dynect::REST::Job - get the status message for a specific Job ID. See "Jobs" below.

• Net::Dynect::REST::Node - delete all types of records under a node (eg, wipe out everything for an FQDN)

• Net::Dynect::REST::NodeList - get all FQDN records in a zone

• Net::Dynect::REST::Password - change passwords for users

• Net::Dynect::REST::QPSReport - get the Queries per second report, with various breakdowns

• Net::Dynect::REST::ZoneChanges - find pending changes in a zone that have yet to be published.

IMPLEMENTATION OVERVIEW

The basic idea to interact is:

1. Get an Auth Token by establishing a Session object. This happens when you call Net::Dynect::REST with sufficient authentication parameters. You can expore the session by looking at your object's session() method. See Net::Dynect::REST::Session.

2. Perform any other requests you want, using this Auth Token (handled transparently by this Perl implementation). Eachof the abstractions need to be passed the Net::Dynect::REST object which should have your session established.

3. Save any changes in your objects so they are ready to publish. Generally this is the save() method on each object.

4. Commit those changes by publishing the corresponding Zone. This will increment the zone serial according to the update style chosen automatically.

5. Logout using the logout() method on the Net::Dynect::REST object.

For example:

my $dynect = Net::Dynect::REST->new(user_name => 'me', customer_name => 'myco', password => 'mysecret');
my $zone = Net::Dynect::REST::Zone->new(connection => $dynect, zone => 'example.com');
my $new_address = Net::Dynect::REST::ARecord->new(connection => $dynect, zone => 'example.com', fqdn => 'www.example.com', rdata => { address => '1.2.3.4' } );
$new_address->save;
$zone->publish;
$dynect->logout;

JOBS

Every Request that is submitted (except one type, see later) is assigned a unique Job ID. You can fetch that by looking at the Request Objects job_id() method. If you wish to get the resquest's response again, you can call the Net::Dynect::REST::Job function with the relevant Job ID - it is thi call to /REST/Job/ that will not have a unique JobID, but the Job ID of the original request. This is useful for long running jobs - the client can disconnect (with its Job ID) and check back later for the eventual return data.

SEE ALSO

Net::Dynect::REST, Net::Dynect::Request, Net::Dynect::Response.

AUTHOR

James Bromberger, james@rcpt.to.