This entry is part 1 of 2 in the series Consuming RESTful APIs in

Over the past four months at Rubrik I’ve got the chance to do a lot of things – presentations, content creation, webinars – all the normal enabling Tech Marketing things one would expect. That said we are really encouraged as TME’s at Rubrik to expand – to learn new things, pick up new skills – even to the point where we can carve off time to do so. One area that I love about Rubrik is its openness as it pertains their API implementation – and with that comes some amazing inline documentation on how to consume them. For those that don’t know me, I have somewhat of a love/hate relationship when it comes to development – I love doing it – I really do. In fact, my college education set me on a path to become a developer – 3 years of Java and some real-world experience changed my mind though – while I find the challenge of development rewarding, I hate when projects turn into these long drawn out time development time suckers.

That said, I love to learn new things, new languages, new ways of accomplishing similar goals – and the standard RESTful architecture provides a pretty good breeding ground for just that. It’s quick to learn, quick to pick up, and quick to execute – so with that, I decided to expand my development horizon beyond just .net and java to other languages – with the first being Ruby. So, without further ado – here’s a quick hit on how to consume APIs using Ruby…


First up, get your gems in order

Before we get too far I want to mention that like almost anything there are many ways to consume an API within Ruby – I explored a few of them – net/http, HTTParty, and RestClient. Now there is no right or wrong package to chose, but in my experience, RestClient seemed to be the easiest to work with (that said I haven’t had the chance to check out all of the Ruby packages related to REST). RestClient is a Ruby gem – a gem is basically a library that contains specific pieces of functionality – think of it like an SDK almost, or in .net terms, a nu-get package. To install RestClient it’s as simple as running gem install rest-client.

gem install rest-client

Time to consume!

Once installed we can now access the RestClient functionality and objects within our Ruby application by simply requiring it at the beginning of our file. Below I’ve also included the JSON library it greatly simplifies the parsing of the responses we will get back from the Rubrik API.

require 'rest-client'
require 'json'

Now we can start to get into the nitty-gritty. For this use-case, we will be simply adding a virtual machine to an SLA Domain within Rubrik. This allows us to showcase a couple of GET requests (one for the VM and one for the SLA) and then a PATCH request (adding the VM to the SLA). Below you can see that before doing anything I’ve simply just defined a few variables to help minimize the amount of typing I do later on – inherently lazy 🙂

vmname = 'MPRESTON-VM1'
slaname = 'GOLD'
username = 'administrator'
password = 'SuperSecret'

With the variable definition out of the way we can get to our first API request – a GET request to the Rubrik cluster in order to obtain the VM ID (VM Identifier within Rubrik) of our given vmname variable.

response =
   :method => :get,
   :url => ''+vmname,
   :user => username,
   :password => password,
   :verify_ssl => false
results = JSON.parse(response.to_str)
vmid = results['data'][0]['id']

So let’s break this down a little bit – Lines 7 through 13 encompass our actual API request. As shown, we can see that Line 8 defines the method of the API request, in our case GET – meaning we are going to GET some information. Line 9 defines the URI and resource we want to retrieve the data from, in our case, the vmware/vm resource from the Rubrik cluster – passing our vmname variable within the URI narrows down the results to only those which match. Lines 10 and 11 simply pass our username and password variables – RestClient will automatically convert these to base64 for us and include them in the headers of the call with basic authentication – something which we would normally have to do manually (another reason I chose RestClient). Finally, Line 12 simply tells the Ruby engine to ignore any ssl warnings which may occur – but in production we never use self-signed certs right? 🙂 Line 8 takes that massive amount of text that is sent back and parses it through our JSON library so we are able to manipulate it like we do in Line 9 and get the exact information we are looking for, the vmid.

So with that let’s go ahead and take a look at another GET request – this time, retrieving the SLA Domain ID within the Rubrik Cluster.

response =
  :method => :get,
  :url => ''+slaname,
  :user => username,
  :password => password,
  :verify_ssl => false
results = JSON.parse(response.to_str)
slaid = results['data'][0]['id']

As you can see it’s a very similar process as to what we did to get the VM ID, just redirecting our API requests to the sla_domain resource within the Rubrik API structure.

Finally, let’s complete our little use case here by sending a PATCH request up to the vmware/vm/vmid resource. A PATCH request normally performs a minor update, or partial update to an object whereas a PUT or POST request mostly creates new objects. In our case, we want to change which SLA Domain our VM is part of and nothing else, so we will use PATCH.

response =
  :method => :patch,
  :url => ''+vmid,
  :user => username,
  :password => password,
  :verify_ssl => false,
  :payload => '{"configuredSlaDomainId":"'+slaid+'"}'

Again, a pretty similar API request to the ones we’ve already processed – however here we have a few subtle differences. First up Line 26 now shows we are performing a PATCH – and when we are patching we normally have to send some sort of body containing the information we would like to update. In this case, we accomplish this on Line 31 where we send a payload, or body, formatted in JSON. This simply just defines the configuredSlaDomainId property with our newly obtained SLA Domain ID. Upon executing the API call we should now be left with our desired end state of having the VM part of the SLA Domain.

So there you have it – hopefully, a quick primer on how to consume and utilize RESTful APIs with Ruby.  I know there is many ways to accomplish this – and it’s quite possible (very really) that I may not be using the easiest way – but its one that worked for me.  Stay tuned as I have a lot of other languages which I’m looking at in terms of REST API consumption – hopefully, I’ll have some posts up around Python, C#, PHP, etc – whatever the flavor of the week is!

Series NavigationConsuming RESTful APIs with c# >>