It’s been a little over a week since our API launch. I haven’t heard from anyone who doesn’t like it, so that must mean we’re doing it right. We’ve been spending time lately catching up on little quirks and documentation bugs. Our first example is up. Its for you Perl jockeys, and really exemplifies the flexibility and power of object masks in your API handling code. We’ve got a .NET one coming up soon. You guys are going to love how easy it is to use this in Visual Studio. We’ve got plans for PHP and Java coming up too. If there’s a language or implementation you want to see please let us know!

In other news, SoftLayer has recently launched a shiny new Facebook group. Sign in and join up to talk with us and get your hands-on exclusive content (which currently is videos of me rambling about the API). As always, we’re here if you have questions, concerns, or just want to chat. See you next time!

Before I get to the good stuff I want to apologize to you guys. I haven’t been active in my API evangelism as of late. Heck, as of the last few months. Well here’s why. I am extremely ecstatic to announce the release of SoftLayer’s API version 3.0! This has been a long time coming here at the SoftLayer devCave. This little gem has been in development for about 9 months now, and it’s very fulfilling to see it finally come out. But enough about how happy we are. Here’s the goods, what makes this different from API version 1:

- The SoftLayer API now explicitly specifies the data types it uses, making it far easier to write in major programming languages like Java and .NET.
- This go around we’re object-oriented. Anything that you can do in it is modeled by a service and data type. Where API version 1 had one endpoint and about 20 methods, API version 3 has about 50, one per service, and about 390 methods. That leads me to…
- It does everything. Seriously, this API lets you manage every single one of your SoftLayer servers and services. In fact it lets you do everything that our portal lets you do (except purchasing servers, but we’ll get to that). For you guys that have been asking, yes that includes DNS management and OS reloads.

We like this API so much that for the past month we’ve been busting our humps rewriting our customer portal as an API application. I just checked our system statistics. Load on our database is down by 25%, and load on our portal web servers is down about 10%. There’s a noticeable improvement in portal responsiveness since we’ve started this project. A great side effect of rewriting our portal as an API application is that when we bust out new services they go into the API immediately.

If you’ve been developing against API version 1 then take a look at our migration guide and FAQ on our brand-spanking-new SLDN documentation wiki. We’re really looking forward to making (and help you guys make) some cool apps with this. This is a big change for us, so please don’t be shy in letting us know what you think. Our forums and email are waiting!

In preparation for the new Seattle launch this Monday we’ve updated getHardwareList() to return a “Location” string at the end of the return array. Location reads “Dallas” for servers in Dallas and strangely enough it reads “Seattle” for servers in Seattle. It’s great to see all this prep-work coming together, though I think we developers will need a nap once the dust settles. In the mean time there’s always Monster.

By now I hope y’all have heard the big announcement about our new Seattle datacenter. We in the dev team got wind of it a few weeks back during one of our super-exciting and ever-informative departmental meetings. The news was met with cheers and sighs. Cheers came because, hey, the first new city is a big deal. We’re growing like crazy. These are some really exciting times for us.

It’s easy to imagine building a datacenter. Find a decent-sized room, throw some raised flooring tiles and cable management around, fill it full of racks, servers, air conditioning, and the like. Slap an Internet connection on top of it, then open the floodgates and relax while the cash flows in. Easy cheesy, right? Wrong! Boy howdy, Pete there’s tons to do, and I’m not just talking about the hardware. I’m talking about the portal.

Our portal is awesome. You can do near anything in it. We absolutely love it. We know y’all love it too, and we want to spread that love to Seattle. All of a sudden servers, vlans, users, and the like have a new and huge differentiator: cities.

Sighs in the meeting came from those of us who realized that every page, ever server, every report, every… well.. everything must be “location aware”. What’s more is we have employees in two places now. We’ve got to make sure that a RAM upgrade on a server in Seattle, but scheduled in Dallas for midnight Central Time actually happens at 10PM Pacific Time. I don’t mind that really. Time zones are one of those features that were on the to-do list but weren’t a super priority. Its nice to get that out of the way. Adding cities into our location code has been challenging in some places, but never overwhelming. It’s getting done and getting done right.

There’s a little under two weeks before the grand opening of the Seattle datacenter, and the dev team is right on schedule. Time zones are already in place, and most of the page changes are coded and in testing. When we flip the big switch up north you can be sure the portal is ready to go.

(This post refers to SoftLayer API version 1. Check out API version 3 for our latest updates.)

Where has the time gone? We’ve been busy in the devCave working out some big projects and improving what we’ve got. In the mean time here’s some new API features for ya’ll to try out:

 
Back It Up
 

You can now query the state of your NAS or lockbox accounts through the API via the getNasSummaryDetails(strNasType) method. Pass along the string “N” or “L” if you want to check NAS or lockbox accounts and it’ll return a list of NAS accounts containing your NAS server’s hostname and IP address, connect username and password, capacity, and the server id and name that the NAS account is attached to. If your NAS account isn’t tied to a server then it returns “N/A” for the attached server hostname and IP address. Its another way to keep track of your services through the API.

 
The Port Authority
 

The Port Control features of the Customer Portal are now available in the API to help you manage your ports programmatically. Now you can get the port SPEED of the given server by using the method, getServerPortSpeed(strServerIdentifier). This function also returns the ID, SERVERNAME, PUBLIC IP, and PRIVATE IP. If you would like to broaden your scope of data, use the getServerPortSpeedList() method. This function returns the same data provided by the former but for all of your servers.

With access to this data, you may find that you want to make a few changes. The updateServerPortSpeed(strServerIdentifier, intNewSpeed, strControlInterface) function was created to do just that. Just provide the ID of your server (IP or Hardware ID), the new port speed that you would like configured (values of 0, 10, 100, 1000), and the interface (public or private), and you are on your way. Not only will the ports for the specified server be reconfigured, but the upstream and downstream connected components will be updated as well.

Give it a shot and let us know your thoughts!

(This post refers to SoftLayer API version 1. Check out API version 3 for our latest updates.)

We’ve updated the API again! This latest refresh sports:

• fixed: getBandwidthList()’s output now mirrors the estimated and projected bandwidth amounts measured by our management portal.
• fixed: Hostnames and domain names in server names are now separated by a period in getBandwidthList()’s output.
• fixed: The Savvis #2 and Global Grossing links are now properly reported in getBackboneList().
• added: The getServerBandwidthDetails() method has been added to the SoftLayer API. getServerBandwidthDetails() mirrors getBandwidthList()’s output for a single server. It returns an array and requires two paraeters:

  strServerIdentifier: A server ID, public IP addres, or private IP address.
  strBandwidthType: The string “public” or “private” depending on which port you want to retrieve bandwidth data from. This value defaults to “public”.

We really should give a shout out to those that have been keeping us on our toes by reporting issues to us on our forums and in support tickets. Please keep them coming. Your contributions are turning the API into a great product. See ya’ll next time!

(This post refers to SoftLayer API version 1. Check out API version 3 for our latest updates.)

I think we on the SLDN development team have it pretty lucky. You can’t beat developing at a datacenter where there are umpteen, wonderful servers to test your code on. Need to reboot a box? Sure! Go for it! After all, it’s just a quick phone call to the datacenter to bring it back online if your test code broke something. In the mean time there are plenty of other boxes to test on. Sure that’s great for us, but it can get hairy if you only have one or two systems to test with. While our sales droids would have you fix that by ordering more servers we on the dev team just implemented a tried and true code test mechanism, the sandbox! Wait, I mean this sandbox!

Our API sandbox is a way for you to safely test sensitive methods without affecting your servers. Method calls from the sandbox will return accurate return data without actually affecting your services or SoftLayer services. Most of our methods are simple get methods; those still work exactly the same. More fun methods like rebootServer() will not reboot your server if called from our sandbox, but will return the same response to your app as if they did.

To use the API sandbox change the API entry point server in your code to api-sandbox.service.softlayer.com. That’s it! Use the same methods and parameters that you’d normally call. The sandbox works on both the XML-RPC and SOAP interfaces. When you’re done testing point your API calls back to api.service.softlayer.com to return to normal functionality.

As always, we welcome your feedback and suggestions. Let us know what you think on our forums. See you next time!

(This post refers to SoftLayer API version 1. Check out API version 3 for our latest updates.)

We’ve put four new methods into the API. They are:

getInvoiceList()
Return a listing for each account that includes the invoice id, date, starting balance, ending balance, invoice amount, payment amount, and account type.

getAccountBalance()
Return the current balance and next bill date for an account.

getInvoice(intInvoiceId)
Retrieve a copy of an invoice in PDF format.

And by request:

getServerCost(strServerIdentifier)
Return the “Total cost of a single server.”

Keep’em comin’, epratt!

By the way, users running each of these methods must have the “View Account Summary” priviledge. You should not have any problem if you can access the accounting tools in the portal.

(This post refers to SoftLayer API version 1. Check out API version 3 for our latest updates.)

We’ve added a new feature to the
Softlayer API: getIPaddressDetails. For a given IP address, this method will retrieve the parent subnet, VLAN identifier, IP address which it is routed to and the name of the server it’s routed to. Instead of using the customer portal and typing in a slew of IP addresses one by one into the public network ip search page, simply call this IP for each IP address, saving you time and typing. It’s incredibly useful for tracking down your secondary IPs.

getIPaddressDetails(strIPaddress)
Retreive subnet and server details for given IP Address

This new method is available via both SOAP and XML-RPC interface.

We’d love to hear your thoughts on this new feature. Feel free to provide any comments and recommendations for improvements on this new API.

(This post refers to SoftLayer API version 1. Check out API version 3 for our latest updates.)

Ask…

And you shall receive…

The newest addition to the API methods has been released and is now available for use. We have improved upon the Portal’s monitoring features by adding just a little more data. In addition to receiving the number of servers that are up, recovering, and down, the new function also returns an array with specific details about the servers that are down. This includes: SERVER_NAME, ID, PUBLIC_IP, PRIVATE_IP, and TIME_FIRST_DOWN, which as requested is “the time that the monitoring system first detected that it was down”.

getServerStatus()
Retreive a server status of UP DOWN or RECOVERING for a given account id.

The new method is available through our SOAP and XML-RPC interfaces. Okay, so we didn’t quite give you exactly what you asked for, we gave you more!