Tag Archives: rest

Hello Chuck. (My "Hello World" in iOS)

Little known fact about me right now is that I’ve started taking classes for Grad school recently.   I had the opportunity to take an iOS class as an elective right now which in my mind is killing two birds as the phrase goes.  I’ve wanted to see how this kind of development worked for some time.   All said I done now that my project is over I think Objective-C programming (I didn’t look into the new fancy swift yet) is a bit convoluted and hard to grasp some idiosyncrasies in the syntax, but overall a good experience.  I wouldn’t call myself a real programmer by any stretch of the imagination.  I’m a decent scripter.  I’m good at quickly figuring out how to make something work and showing it off, I guess in my work world we would call that a proof of concept.   But I am by no means elegant or efficient.   I leave that to much smarter people.

My idea was that I wanted to learn how to do REST api communication from an iOS application.  I planned to do something relatively simple for my class project that would teach me the basics, and then later I would build something bigger, perhaps to integrate into some of my other mad scientist-like projects.  And that is exactly what I did.

Behold, Hello Chuck.

Screen Shot 2014-06-26 at 9.54.44 PM

I’ve posted about other fun REST api’s previously like FOaaS but I do not believe I have talked about The Internet Chuck Norris Database.   This web service consists of a few simple REST endpoints that will return a chuck norris joke.  Simple right?   As I am typing this their website is down (or they are filtering me due to all my API calls in developing the app…) so I’ll reference an archive.org link here.

The most simple use case is a GET to http://api.icndb.com/jokes/random to retun a random joke:

Screen Shot 2014-06-29 at 8.57.38 PM


I learned how to persist this data in multiple ways within the app with Archives, SQLite, and Core Data.   Showing the jokes from storage in a table view.   Neat stuff:


Screen Shot 2014-06-26 at 9.53.24 PM


I had to add a few more use cases to the app for the class so luckily there were a few other end points available.   One inputed a firstname and a last name to customize the joke.  In the app I made it look like:



I also added functionality to pull multiple jokes at once from an endpoint, and one that produced a joke from the ID key.   Not very sexxy to show off but were good use cases to learn how to develop.

All in all it was a fun project that exposed me to a new technology.  I have a ton of ideas for new apps I’ll probably only get a chance to develop 5% of them.   We’ll see.   I did submit it to the app store this past week, though I’m sure it will be rejected based on the usage of a a celebrities proper name.   Damn you Apple Censor Board!

If it does get posted, check it out!



Tagged , ,

JAAS Project Madison: VM AutoWake /w RFID

September 29 2013:
Adding content from GitHub

Files hosted on GitHub HERE

Parallax RFID Card Reader /w cards (Radio Shack 276-212)
Raspberry Pi (Adafruit 998)
Pi Cobbler (Adafruit 914)
Logic level converter (Sparkfun BOB-11978)

VMware Orchestrator
VMware vCenter
Tiny python script

This idea simply came from the thought ‘i wonder if it’s possible…’   I’ve always wanted to build something with RFID, and I’ve always wanted to play with a Raspberry Pi, so no time like the present.

The thought here is to simulate swiping your badge at your office in the morning when unlocking the door, and automatically have it wake up your desktop virtual machine so it’s ready for you by the time you need it.

Initial tests with the hardware went well:

I can’t claim credit for the wiring of the rPi and RFID reader.  Check out this blog for the exact connections.  It’s really easy.  The pi cobbler makes it easy to prototype stuff on a breadboard.  The logic level converter is so you don’t fry the rPi from the higher voltage the reader needs.


(1) A simple python script loops reading serial data from the RFID reader.  (Based on this post.)

(2) When a badge is read, a sound plays and a call over REST is made to vCO to invoke a workflow.  The badge ID is passed to the workflow.

The rest of this (but not REST.. ha ha. nerd joke.  ok sorry.) is within a vCO Workflow.  At the current time it’s more or less one workflow which isn’t super elegant, but I had issues doing certain operations when separating it out.  A future revision will make this part better.

(3) The workflow takes the badge ID, looks it up in a SQL DB (i wanted to test doing operations on an external DB too), gets the employee ID, – albeit overkill, I wanted to give it more real world context and functionality.  Think of this as an integration with a 3rd party security system, and a HR system or Active Directory.

(4) The employee ID is used to lookup the name of the desktop from another database table.

(5)  The workflow does some magic to find what the exact VM object is from the string of just the name.

(6) VM is powered on.

Pretty basic, but this covers an external VCO invocation over the API, external DB CRUD, variable manipulation, and VM power operations.

Here’s the full video overview:

All done for now.   The rPi is off mining bitcoins on a shelf until it’s called to duty next. Stay tuned for a new project in a few weeks..

– Clean up the vCO, make it more modular
– Python script reads badges way too fast causing duplicates
– Package up content and post here (workflow + python)


I take really good notes, but I may have missed a site that was helpful, sorry if I missed you!

Further Details  here

Back to the Main Project Page

Tagged , , , , , ,

Weather Underground Part 1: Invoking a GET method on a REST web service /w an API key in vCO

Consider this part 1 of 2 using Weather Underground.   First we need to gather data.

Feb 22 2014 – Typo in workflow name updated.  Thanks Phil

This post is a bit less exciting than the last FOAAS post. The concept here is important to grok however to be able to build on and do anything more advanced.

Introducing the REST interface for Weather Underground.  The API reference is here.  This page gives a good visual example of forming a API request and seeing the return as JSON.


Awesome, simple enough.  Shouldn’t be too different than dealing with curse words.     Because I always have been and always will be a lazy sys admin, we’re going to build on existing modules.   Add the Weather Underground host to vCO:


And form the URL in an REST operation in vCO as follows.  Note we’re using parameters in the URL template for KEY, STATE and CITY.  This operation is GET http request.


Now if you haven’t done it already, we need to sign up on Weather Underground for an API key.  Most web services work this way.  Instead of doing http authentication, you have a long unique key that you pass to prove you are who you are so they can track you.    It’s free on this site for 500 calls per day and 10 calls per minute.  Perfect.  Do that here.

We have our key, let’s test our connection with the built in ‘Invoke a REST Operation’ workflow.  Use the API key you were give, put in a State and a City:


And if all goes well, in the logs we should see the JSON formatted output (remember the last line of the workflow to posting the response as a string).  Snippet of the output:


Excellent!   This gives us a lot to work with.   Now let’s make this more real.  Duplicate this ‘Invoke a REST operation’ to one of your own, I call it ‘Invoke REST 2’  (never-mind the #2, i’m blogging this out of order as I’ve already done part two of this blog post).   I create a brand new workflow that passes parameters to that one to show how to nest workflows.

But first let’s modify the new ‘Invoke REST 2’ workflow.  Through some trial and error I figured out how to address individual parameters that we are returned in the JSON response.  For example, to make this stuff more meaningful it would be great to get the temperature in fahrenheit.   So we run the JSON.parse subroutine, and pull out the data as such.  Also we’re going to grab the time and location:


Now just to prove it still works, we can run just this one workflow real quick, pass the parameters and we get:


Excellent (and BRRRRR it’s cold this morning.  What the heck, winter is here?!)     Now that we’re doing something a little more fancy with the data, let’s create this brand new workflow I alluded to.   I’m calling this ‘Weather Underground 001’.

This workflow will have attributes for the api key, the name of the rest operation that we added, and the message body (this will be used later to pass data further along the workflow).  These are the hard coded attributes for this workflow.


The inputs we’re going to prompt for all City and State:


The outputs (irrelevant for this part as we are not passing them anywhere, but important for part two), are as follows:


And now some of the awesomeness of workflows – the “smart visio” schema.   This is how we drop elements into the workflow to do work.  For this part we’re just using the ‘Invoke REST 2’ workflow, so drop that in there:


Staying a bit high level for now, we need to connect up what is being passed into and out of this workflow with the Visual Bindings tab.  This is where we tell it what we need to do with city, state and key (and what the name of the REST Operation is).   This is also where we get the message variable we will do something with later.

This concept is key to using vCO as it’s intended.  We are re-using workflows, not re-creating them.  So there is no special scripting to do as it was already done in the workflow we embedded.


Save the workflow and increment the version.   Run this guy and you should see similar output to when we just ran the embedded workflow stand alone:


Still cold!    Awesome.  This is how we can connect to a REST web service, use an API key and pull out a specific value or three.    In the next part we will show embedding a second workflow and passing a value to that one to do some work with.

Tagged , , , ,

Fuck Off As A Service /w vCO and REST API

Consider this a Hello, World exercise for vCenter Orchestrator (vCO) and a REST API plugin.   With vulgarity.  Put the kid to bed, or drop a dollar in the curse word can because it’s about to get ugly.

There’s a web service I came across this summer called Fuck Off As A Service that is a RESTful service that will respond via plain text, JSON, or HTML based on the data you send it.   Let’s explore the most basic use case.

The first one listed is:


If you format it in a web browser with the URL http://foaas.com/off/Congress/The_People   you get back:


Neat huh?   So let’s do something in vCO to prove we can talk to a REST web service.   I’ll leave to to Those Better Than I to describe how to set up vCO and what not.  So I’ll jump in after the REST plugin is installed and vCO is restarted.

First, we need to add the web service as a host.


We want to give it a name, and enter the URL:


Since this is a totally public service we do not need any authentication:


You’ll notice the green check mark indicating a successful add.   Now we need to add the operation.  Think of the operation as a specific action we are calling.


This workflow has a few more boxes to fill in.  We need to choose the host the action will always be taken on.   We give it a name.  We form the template – this is key.  This corresponds to the API documentation of the web service we are dealing with.  Use stuff in brackets {blah} to indicate the parameters.  In this case we need to give it two names.  And a HTTP method.


Save it and we should be good to go:


OK now let’s see if it works.   Just to do a simple test we’re provided a pre-built workflow to invoke rest operations.  So right click and start that guy:


Choose the “off” operation we were just adding:


Since this is just a pre-built demo workflow it’s not properly asking for the names but it does know we have two parameters.  So enter the NAME and FROM parameters here:

EDIT: I didn’t realize spaces causes it to puke, not sure if it’s on the vCO side or the FOAAS side but put an underscore in there and you’re golden


Unless we broke something along the way, we should see it run successfully as such:


Now to see the output click on the Logs tab of the workflow we ran.  At the very bottom you should see:


Boom.   Take that, Congress.   So this is a very simple example but shows that we do have the power to interact with a web service from within vCO.   You can do any number of things with this now.  You could make a popup error message in a VMware product contain this kind of vulgarity.    A user tries to deploy more VMs in vCD than they have quota for and you could respond with a customized message with their user name.    Vulgar awesomeness can be done.  Or at least vulgar wastes of time while you learn yourself some vCO.

Tagged , , , ,