Logan, the chief architect behind our API framework, has been playing with graphviz lately to make pretty pictures out of our codebase and help find areas for improvement. You’d be surprised at how much a map of your object relationships can help make your structure more efficient. These pictures looked so cool that I asked him for a diagram of our API’s object relationships.

The picture below represents how each API data type relates to each other. The ones with the most lines connecting them to outher types are SoftLayer_Account and SoftLayer_Hardware. Go figure. : ) Here’s an SVG version of the image or click on the image below for a higher resolution version for your viewing pleasure. It looks most impressive when printed out and taped to your cubicle wall. Enjoy! See y’all next time.

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 a Java SOAP example up on our downloads page. This was written in Eclipse 3.2.2, and for your convenience the example package contains our Eclipse project files. The code should run on JVM version 1.4 and above. We’d love to hear your feedback on this example. Reply here or post on our forums and let us know what you think. See ya’ll later!

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

Howdy, everyone. The SoftLayer dev team has been growing a bit lately to handle new portal additions and adding fancy new methods to the API for ya’ll. So far we’ve gotten some great feedback on the API and how to make our application servers work better for you and your businesses. Now that we’ve got the API out and some extra head count what say we kick into high gear?

Here’s our game plan. We know how smart our customers are. We know how they think (we hope). They’re geeks who find perverse joy in taking things apart, reassembling them, and building cool new toys out of the leftover parts. We want you to give that a try with our API. Our Implementations Forum has a good start, but we’re looking for something to really knock our socks off. So far the coolest thing we’ve seen is a Yahoo! widget. Who can top that?

Email us, post to the forum, or leave a comment here with sweet implementation goodness. Surprise us. Show us what wacky stuff you can do with your server and our API. If you don’t code then that’s fine. Send us your ideas. Maybe someone will pick up on it. To get the ball rolling we’ll write an app or two of our own. Even better we’ll release the source of our app to get ya’ll started. Let’s see what kind of cool programs we can write.