Greetings fellow SLAPI enthusiasts! When the call went out for examples I figured why not cowboy up and try my hand at with a .NET example. After all, being an MCP in a largely PHP shop makes me as qualified as anyone. Plus I am constantly pushing the Microsoft Kool-Aid around the office so this was a chance to put my money where my mouth is.

Unfortunately, there was just one catch—I’m not a .NET programmer. I’ve got 10 years of experience writing drivers, protocol suites, and firmware. In other words, C/C++ with a little bit of assembler thrown in when push comes to shove. Sure I can write a c-sharp application, but I’m pretty green at it and until a month ago if someone had told me they had a problem with their WSDL (pronounced wiz’duhl) I would have wondered why they were telling me instead of their urologist!

That said, what follows is a pretty basic SLAPI example, done in both C# and VB.NET (because I’m ambi-dot-dextrous). Don’t expect anything more than a DOS-style command console for the UI. I’m used to letting the Microsoft’s control panel give the user any feedback and usually consider my code to be ready to ship if it can run for 24 hours without blue-screening the box!

My chops are on display at the SLDN API Wiki. Let me know what you think!

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!