eNom Repost: Using the Enom Domain API: Node-Enom-API

[Reposted from an entry on the eNom Blog.]

There are a ton of Enom developers out there, all doing cool things with our API. This series will focus on code samples, tools, posts and wrappers written in a number of different languages with a number of different goals. In the coming months, we will look at implementations in C#, PHP, Perl, Java and more (even a GO implementation!). I may also include releases from Enom as we build up our code samples and utilities in an effort to make it even easier to get up and running with our API. A great deal of amazing work is being done in the developer community, and a ton of it is happening on GitHub. For those of you not familiar, GitHub is a lot of things: a software repository, a version control system and a social network of developers all working together. This is where we will get most of the projects we will be discussing.

Aside: I selected these projects myself, and they have only been tested a bit by me, @RghtsideSean. Be sure to do your own due diligence and ensure a project is right for you and written in a secure and design-sound way before using them in your production code.

Ok, disclaimer out of the way, let’s look at what we have for today. Many interesting things are coming out of the Javascript community. What was once thought of as a limited scripting language has become the backbone of fast, dynamic websites and even mobile phones! (R.I.P. WebOS). Today we have a Javascript project from GitHub, Node-Enom-API. This was created by a developer whose username is CIDeveloper, and the project is located here.

Introduction

As is stated on the GitHub page, “Node-Enom-API is a simple library to interface with the Enom API”. It allows you to work in Javascript without rolling your own wrapper code for building query strings and calling the API. This is a tiny wrapper, as it does not have any knowledge about the request and response types, nor does it handle errors or property validation. It simply bundles up all of your info, sends it to the API and hands you back the results. In a lot of instances this is all that is needed. Should you need more (specific objects for response types, etc.) write them and get them up on GitHub! Let the world know so we aren’t all recreating the same wheel. 🙂

Setup

To use, either place the files in your project or install the package using:

npm install node-enom-api --save

Once you have the files in place, you need your application source to include the wrapper. This is done with:

var Enom = require('node-enom-api');

That is it for setup. Now we will move on to using the wrapper.

Usage

As stated above, this wrapper consists of a single method which takes in a command name and parameters in JSON format. First we need to instantiate the object with our options:

var Enom = require('node-enom-api');

var client = new Enom({
  uid: "resellid",
  pw: "resellpw",
  response: "xml",
  mode: "testing"
});

The uid and pw arguments are your credentials. The response parameter indicates which response format you wish, JSON or XML. Note that this is NOT the same as the API responsetype value, which supports XML, Text and HTML. This is specific to the wrapper and can return either the raw XML response or a converted JSON collection. Finally, the mode parameter indicates which API URL to use, either the live production site or the testing site. If “testing” is specified the test URL is used. If not, then the production URL is used. Next, we make the call:

client.get('Check', {sld: "unusualTVname", tld: "tv"}, function(error, data){
  if (error) {console.log(error)};
  console.log(data);
});

This call is issuing the Check command to see if the domain unusualTVName.tv is available. Since we provided our credentials when we created the object instance, we don’t need to specify them here.

Noted Issues

This wrapper is handy, but there are a couple issues. When I have a bit more time, I hope to make changes and do pull requests for them. For now, I just wanted to let people know about a couple things:

  • If you specify the ResponseType parameter in your parameters on a method call, your string will end up with your parameter AND a hard coded ResponseType=XML parameter. Behavior will be strange-ish at best.
  • As stated above, the mode parameter defaults to production unless the specific string “testing” is used. I might think about making testing the default to avoid inadvertent typos resulting in production purchases. 🙂
  • Util.js appears to be an empty file.

Conclusion

Thanks for reading this far and hopefully this will save you some time. Please feel free to drop me a note on Twitter at @RghtsideSean and let me know any questions, comments or thoughts you might have!

Leave a Reply

Your email address will not be published. Required fields are marked *