When I first learned about object oriented programming, many years ago, I found that the technique fit me well. I found the process of breaking a computing problem down into objects to be a natural way to analyze many of them. At the same time, my designs are never as elegant as I would like them to be in the first draft. For me, the object oriented design process involves tinkering with the design, trying a couple of iterations, and refining the deconstruction over time. I prefer to work with prototypes and explore their interaction before settling on a final implementation.

When I wrote software in C++, however, I discovered that the language made prototyping difficult. I wanted to focus on objects and their interfaces. Unfortunately, C++ wanted me to concentrate on a number of picky details, the types of the objects, what their constructors might require, and most annoyingly how the source files should be squeezed into a project for the benefit of the compiler. Increasingly I found that the rigor of these details forced my focus on the tools, and not the design I was trying to study. Because of that, I did much of my prototyping in Smalltalk, more specifically Squeak Smalltalk.

Smalltalk is the language that originally coined the term “object oriented”. It is highly dynamic, weakly typed, and above all easy to learn. Squeak’s implementation is interpreted, rather than compiled, which means I could make small changes, and see them running almost immediately. The downside to Squeak is that it lives in its own environment. As with the C++ project/compiler, the Squeak environment requires a bit of struggling with the tools when you want to focus on design, but overall the environment was much more forgiving and offered faster turnarounds than C++.

I didn’t stop looking around for an even better way though. I like to learn new things and I’m a bit of a programming language geek anyway so I’ve tried lots of them. Eventually I found a new language for my prototypes, Ruby.

The Ruby programming language is a bit of a mutt in that it combines features of many other languages, including Smalltalk. Like Smalltalk, Ruby is a pervasively object oriented language, very dynamic, and uses a weak typing system. Unlike Smalltalk, however, Ruby doesn’t have its own environment. In fact, Ruby requires very little in the way of overhead. The language interpreter operates on simple text files and it can be invoked from the command line in a terminal. When prototyping, I find that the simple tool-chain keeps the turnaround after any change to a minimum. For me, that makes Ruby just about ideal.

As an added bonus, Ruby proved to be very helpful in other ways. The language has a full-featured standard library, as well as a thriving community that generates many helpful tools. While I started using it for prototypes, I quickly found other uses for Ruby. For example, at a previous job, on a cross-platform application project, we wanted a single build system that worked on each platform. We wrote it in Ruby, using the object oriented features of the language to factor out platform-specific behavior. The strategy was a solid success.

When I joined the SLDN team, I had been working with Ruby for an number of years. However, it had always been a secondary concern, a tool I picked up along the way to help me reach some other goal, rather than the focus of my effort. As you might imagine, when I started at SoftLayer I was presented with a new opportunity.

Our team’s primary responsibilities is helping developers use the SoftLayer APIs effectively. Before I got here, the team had developed many samples demonstrating how to call the SoftLayer API from different programming languages. Perl and PHP were early examples. Shortly after I arrived a Python sample followed. The similarities in functionality between Python and Ruby identified Ruby as a natural target for implementation. Ruby would also have an added benefit in that it satisfied a pent up desire for a sample in a language, any language, whose name didn’t start with the letter “P”. As the new guy on the team, with some Ruby under his belt, I was given the task of putting a code sample together.

One of the biggest decisions I had to make, right off the bat, was how the code would access the SoftLayer API. The samples we had for other languages relied on either SOAP or XML-RPC. Recently, however, we opened up another mechanism, inspired by the Representational State Transfer (REST) paradigm. I was more familiar with the REST interface than the others, having used to implement the SoftLayer Mobile Client. Moreover, support for SOAP and XML have been removed from the standard library of the latest revision of Ruby, Ruby 1.9. This was done in favor of the wide array of external libraries offered by the Ruby community. By using the REST interface, I would avoid having to tie the sample to one particular implementation of XML technologies to the exclusion of others.

After settling that question, I put my prototyping skills to work trying to find a nice programming model. For once, my prototypes were in the target language, a refreshing change I assure you. I did want to keep the Ruby code sample noticeably similar to the exiting Python code so many decisions from lifted from that sample. At the same time, it would not do to copy the Python design exactly. It was important that a Ruby client fit property in the Ruby language.

Once I had written the code, I prepared it for distribution as a source repository. A colleague, however, suggested that we take the extra step and package the code as a Ruby Gem. The Gems system is a mechanism for distributing Ruby libraries, very similar to the CPAN modules of Perl, or Python’s Eggs. As a Ruby programmer, I’d used Gems many times, but I’d never created one. Doing so required us to change the code a bit, and restructure the directory. On the whole however, the process was straightforward if not downright easy.

Creating the SoftLayer API code sample was fun. It was a quick, concentrated effort, and I’ve already found the resulting library to be very useful. The SLDN team would like to welcome you to check it out yourself. The source for the SoftLayer API Client for Ruby can be found github in the SoftLayer repository, http://github.com/softlayer/softlayer-api-ruby-client. You can also install it for your Ruby distribution as a Ruby Gem. Developers using jRuby users should look for the softlayer_api_jruby gem. Other Ruby distributions should install for the softlayer_api gem. All three distributions include examples that demonstrate how to use the library. The library is intended as sample code and you should feel free to improve upon it for your own use. If you add a particularly useful feature, find a bug, or would like to make a suggestion for improvements we can make ourselves please let us know either on the github page, or through the forums.

In our last post we mentioned that our API now supports a REST interface. It’s really true, and it’s really here! Quoth our new, fancy, manual page:

REST API URLs are structured to easily traverse SoftLayer’s object hierarchy. A basic REST request is structured as follows:

https://<username>:<apiKey>@api.[service.]softlayer.com/rest/v3/
<serviceName>[/initializationParameter].<returnDatatype>

• All REST requests, even private network requests, must be passed through HTTP SSL.
• Use your API username and key to authenticate your request through HTTP authentication.
• The base hostname and folder name for a REST request is either api.softlayer.com/rest/v3/ or api.service.softlayer.com/rest/v3/. Use api.service.softlayer.com/rest/v3/ to access the REST API over SoftLayer’s private network. It’s a more secure way to communicate with SoftLayer, but the system making API calls must be on SoftLayer’s private network (either purchased from SoftLayer of logged into SoftLayer’s private network VPN).
• Follow up the base URL with the name of the API service you wish to call, for instance “SoftLayer_Account” or “SoftLayer_Hardware_Server”.
• If your API request requires an initialization parameter then add a slash followed by your init parameter id to your URL.
• The SoftLayer REST API can return either XML or JSON formatted output. Add “.xml” or “.json” to the end of your request to specify which format you’d like to receive data in.

Now that the boring stuff is out of the way here are a few sample calls:

The most basic call in the SoftLayer API is the getObject() method in the SoftLayer_Account API service. It also has the simplest URL in our REST API:

https://username:apiKey@api.softlayer.com/rest/v3/SoftLayer_Account.json

If you need to retrieve a particular object then append its id number to the end of the URL. This URL retrieves information about the SoftLayer_Hardware_Server record 1234:

https://username:apiKey@api.softlayer.com/rest/v3/
SoftLayer_Hardware_Server/1234.json

One of the coolest things in our API is how all of our objects relate to each other. Append a relational property to the end of your URL to retrieve that object’s related objects. This URL retrieves server 1234’s network component records:

https://username:apiKey@api.softlayer.com/rest/v3/
SoftLayer_Hardware_Server/1234/NetworkComponents.json

Chain these relational properties as far as you need to go. You can also specify single relational properties by adding its id to the end of the URL. This URL retrieves network component record 5678 from server record 1234:

https://username:apiKey@api.softlayer.com/rest/v3/
SoftLayer_Hardware_Server/1234/NetworkComponents/5678.json

Since hardware records relate back to the SoftLayer_Account service, your URL can also relate back to it. Your SoftLayer_Account record has properties for nearly every service available to you, and is handy for providing a truly RESTful interface.

https://username:apiKey@api.softlayer.com/rest/v3/SoftLayer_Account/
Hardware/1234/NetworkComponents/5678.json

I’m absolutely loving how well this works. Being able to test API functionality right in my web browser has made troubleshooting a lot easier on me. Our REST interface also supports object creation, edit, and deletion and SoftLayer API specific options like object masks and result limits. Check out our manual page for the scoop. Please give it a whirl and tell us what you think. We’ve got more good stuff coming your way soon!

Some of you have noticed that we mentioned our new mobile clients are based on our developer API but don’t require a VPN connection to our private network. Your observations are astute and indeed correct. Our iPhone and Android applications can be accessed from anywhere on the Internet, and now so can the SoftLayer API!

We’ve rolled out API endpoints on the public Internet at https://api.softlayer.com. Our public API uses SSL to keep your data transmission secure, but you’re still free to use non-SSL HTTP on our private network. Here’s a rundown of our API’s endpoint locations:

SOAP:

• https://api.softlayer.com/soap/v3: public network
• https://api.service.softlayer.com/soap/v3: private network

XML-RPC:

• https://api.softlayer.com/xmlrpc/v3: public network
• https://api.service.softlayer.com/xmlrpc/v3: private network

REST: (That’s a new one. More on RESTful services soon!)

• https://api.softlayer.com/rest/v3: public network
• https://api.service.softlayer.com/rest/v3: private network

The private network endpoints at api.service.softlayer.com are still up and aren’t going anywhere. In fact, we still recommend using the private network to send API calls from your servers and cloud instances in our datacenters. But those of you developing desktop and mobile clients have a whole new world of access. Our public API clients will soon be updated to use our public endpoints. Try these out, log into our forums, and tell us what you think!

Much of the development work that goes on here centers on the SoftLayer Customer Portal. The Customer Portal is a traditional Web application that links your browser to the powerful back-end systems that our engineers have crafted over the course of many years. Most of the engineers around here are first rate hands at web application technologies like PHP, JavaScript, and HTML.

I don’t know much HTML. I know even less PHP. I spent many years working on desktop Macintosh applications in C and C++. With the introduction of the iPhone SDK, a new job opportunity made me an iPhone developer. The leap from the Cocoa framework, on the desktop Mac OS, to the Cocoa Touch framework of the iPhone was not difficult at all. The two frameworks share a lot in common and the parts that are different still share a lot of design patterns. All in all, making the transition to a company whose primary focus is web development was a lot more intimidating than picking up the iPhone API.

I joined SoftLayer specifically to work on the Mobile Client. The goal of the SoftLayer Mobile Client is pretty straightforward, put the essential parts of the SoftLayer Customer Portal in the palm of your hand, on your favorite mobile device. We wanted to move beyond the mobile web applications the team had already created, and craft an application with a look and feel only a native applications can provide, a first rate user experience.

At the same time, all the attention to detail you can possibly give the front end doesn’t matter unless you have some way to communicate with the server. That’s where the SoftLayer v3 API comes into play.

The smart folks on the the web application development team work behind the scenes on the server, enjoying full access to the complex machine behind the SoftLayer Customer Portal. Their target has been a traditional web browser, running on a computer with Gigabytes of available RAM, Gigahertz of processing power, and several Megabits per second of network connectivity.

Comparatively, on the Mobile Applications development team, we live across the wire on tiny computers with small pipes. Mobile devices have limited memory constraints, run on a “slow” 3G networks, and have processors running at less than 1/3 of the speed of their desktop counterparts.

With such vast differences between the environment of a desktop computer’s browser and an application running on a mobile device, SoftLayer could have crafted a custom API to give our mobile applications access tailored access to the machine behind the SoftLayer Customer Portal.

But we didn’t want to do that.

With great pride of principle, our mobile applications team makes it a point to use the same API that SoftLayer presents to you, the third party developers of the SLDN network. We don’t want to use back doors, and we don’t want to use secret calls. Consuming our own API, “eating our own dog food” as the saying goes, gives us a unique vantage point which we hope to use to improve the API for all SLDN developers.

In the course of developing the Mobile Client on a variety of platforms, the mobile team has found that most aspects of the SoftLayer API work very well! We’ve also found some that presented challenges to our mobile devices. Lucky for you, however, we’re working very closely with the web development team to remove those challenges.

We plan to bring new functionality that results from our experience directly to you. In the course of the next few months, look for some changes (large and small) to the services we provide. We hope you will find them a benefit to your application development regardless of where your application runs.

Lately I’ve seen a lot of people around me writing and hacking in Python. Way back when API v1 was out we noted that Python has built-in XML-RPC support. Built-in XML-RPC support is great. It makes calling our API, especially our latest API, a snap. Some of y’all on our forums have been doing very cool things with our API in Python.

Python hackers and users, we’ve just made your lives easier. I’m pleased to present our latest language tool for your API toolbox, a Python library for the SoftLayer API. This library functions very similarly to our PHP and Perl clients. Before you had to juggle API call headers to pass along things like initialization parameters and object masks to your API calls. Now you all you have to do is declare an API client object and run methods on it. It’s much easier and saves a lot of coding on your part.

I’ve been talking to a lot of people who are building dynamic Cloud Computing Instances using our API. I wrote a simple example for one of our forum users a while back to accomplish this task in Python using it’s built-in XML-RPC support:

Here’s that same functionality using our new Python library:

This saved 20 lines of code and is much easier to read. Our client is supported in both Python 2 and Python 3 and has a handy installation script. Please download it, go nuts, and speak up on our forums, IRC channel, or a support ticket if you have any questions. As always, we’re happy to hear your feedback. Thanks, everyone!

http://github.com/softlayer/softlayer-api-python-client/

An interesting facet of the development and systems administration business is the number of 80% projects that build up over time. An 80% project is that awesome library, script, rewrite, new system, or what have you that’s cooling on your back burner. It’s almost done but it’s missing the finishing touches. Maybe it needs a few code tweaks. Maybe it needs a little more documentation. Maybe you’re still finalizing settings and playing with patches. Don’t lie; we know you’ve got these projects hanging around. I’ve got a list of 80% projects as long as my arm.

It’s time to check something off my 80% projects list. I’ve finally finished documenting and am happy to release the SoftLayer API Perl client library! This module will make Perl API hackers’ lives a whole lot easier. Previously you had to build SOAP API calls manually using the SOAP::Lite module and parse the response into something easier to handle. Now you can accomplish the same thing with a series of easy to use helper methods. Functionality is very similar to our PHP client but with a Perl twist. For instance, you can do clever one liners!

use SoftLayer::API::SOAP;

# Grab my account information.
my $account = SoftLayer::API::SOAP->new(
    'SoftLayer_Account',
    undef,
    'my API username',
    'my API key')->getObject();

Check out our README for many and more comprehensive examples. Download the library from our github page at:

 

http://github.com/softlayer/softlayer-api-perl-client

 

As with all of our projects we’re very open to feedback, so please comment or post on our forums and let us know what you think. I can’t wait knock a few more 80% projects off the ol’ list. You’re going to love them. See y’all next time!

After a three hour flight that took five hours from LA to Dallas I’m finally home from the Southern California Linux Expo. This was SCaLE’s 8th show, an evolution that started as a meeting of Linux User Groups from the Los Angeles area that grew into one of the largest Linux, open technology, and community focused events in the region.

This is my second year attending SCaLE. I went last year as a part of an open source project I was working with and had a pretty good time. I jumped at the chance to go again when I found SoftLayer had a booth at and was sponsoring SCaLE 8x.

I’m really glad I went; I dig these community-focused events. What strikes me about these events, and SCaLE in particular, was the general optimism of the staff, attendees, speakers, and exhibitors. This show is on a weekend, and people came because they genuinely care about FOSS, cool new (and sometimes old) tech, and community advocacy. Most attendees fit the classic nerd stereotype. We got to meet our fair share of skinny pale guys, scruffy and ponytailed sysadmin types, and bearded folks with wallet chains and Star Trek t-shirts.

When not working our booth I was able to duck out and attend some of the talks at the expo. Aside from being informative (I picked up a lot about technical writing that I can’t wait to throw into our API documentation), every single talk I attended was completely packed to the point where there was standing room only. It’s refreshing to see speakers talk about things other than the company they work for. Instead, they focused on cool tech or how to be more productive in your community or with a specific technology. I took pages and pages of notes this weekend, it felt like being in school again.

I think SoftLayer did well at SCaLE 8x. We got our name out like we usually do at these events, and got to introduce a new group of people to SoftLayer and our ever-changing and sometimes hidden industry. I hope we’re sponsoring SCaLE 9x. Even if we don’t you’ll still find me there. See you next year!

We’ve opened up the backend API that powers our CloudLayer Storage systems for y’all. Those of you who want more control over your cloud storage accounts and content should definitely check this out.

We’ve got instructions conveniently hosted on our cloud systems:

CloudLayer™ Storage API v.1 Documentation (1.3MB)

This is a bit of a departure from our standard API. It only covers manipulation of CloudLayer Storage accounts, and is accessed via REST-full URLs. Head dev honcho Nathan gave us a rundown of how to access it in curl a while back. It’s incredibly powerful and gives you complete control over what you host and share on the cloud. Give it a try and let us know what you think!

Every year I get the same question from my customers, “Hey Klaude, are we going to see you at HostingCon this year?”. Every year I respond with the same thing, “I have no idea. I’ll ask!”. Every year I hear from my management, “Not this year, Kevin.” after I ask if I can go. Representing SoftLayer at the big trade shows is a coveted job amongst the SoftLayer enlisted, especially for an event like HostingCon.

This year I was asked the same thing I’m asked every year, but this time it was suggested that I could probably tag along with the cool kids if I gave a talk or ran a session. That’s a pretty good idea. I pitched it to my boss, and to my surprise he agreed. That’s great! Now all I have to do is schedule a presentation, and I’m set! A month or so full of research and agonizing over minutia has led to a talk I’ll be giving with Ilya Baimetov from Parallels about providing services with APIs. Our slot is at 3:00PM on Wednesday, August 12th. Stop on by if you’re in the Washington DC area, want to see a giant collection of businesses in the hosting industry, and want to visit the guys who run your favorite dedicated and cloud hosting company. When not speaking you’ll find me at the SoftLayer booth giving API demos and free hugs.

SoftLayer is well represented in the HostingCon event schedule. Our CFO, Mike Jones, is headlining Monday’s keynote “Surviving the Financial Crisis”, and CTO Nathan Day is participating in Tuesday’s general discussion “Offering Cloud Services to Your Customers”. The event runs form Monday, August 10 to Wednesday, August 12 at the Gaylord National Resort and Convention Center in National Harbor, Maryland. We’d love to meet you. Drop on by and say hi!

If you haven’t done so yet, please migrate your apps and scripts based on version 1 of the SoftLayer API to version 3. Version 3 is chock full of tools and methods that touch every single facet of your servers, your account, and our business. If you’ve been following threads on our forums since last March then you’re likely using our latest API and don’t need to migrate anything. We’ve sent notices to those of you who have recently used API version 1. Check out the migration page on our wiki for some tips on how to update from version 1 to version 3.

We plan to turn the old API off on August 1, 2009. Please post to our forums if you need help migrating or open a support ticket if you’d like to work one-on-one. Thanks, everyone!