I love Steri Stumpie

June 15, 2009

Seriously, it’s no lie.

This is what I am thinking on my day off (thank goodness for tuesday holidays = looong weekends) as I am slowly sipping a perfectly chilled chocolate stumpie. Some might crack a beer to sip on the couch, but me, I crack a Stumpie. hmmmm.sterisite_640

The last week or so I have been dragging the occasional Steri Stumpie to work, much to the dismay of my colleagues who tell me its not the manliest thing to be seen drinking behind your desk. I think they may just be jealous, envy is such a nasty thing. If you don’t have anything good to say you’d better just ‘sharrup’, so there you bastards!

*Sip*, hmm velvety chocolate delight.

Funny I was “off the stump” for a long time, you see I had a short affair with Super M from Clover, but that ended in tears, tragic really. Then as if the planets aligned in just the right way I spot this case of 24 Chocolate Steri Stumpies in Makro and through a combination of blind lust and price miscalculation I tossed the case in my trolley and wham, 13.5 bottles later and I am hooked.

One sec … Bloody hell, that was a good sip …

stumptwitter_640I see there is a social media campaign brewing for the elixer of the gods over at http://www.steristumpie.com/ you can become an “Ambassador” if you perform some wacked out stuff on video using a Steri Stumpie .. hmm .. maybe later, I am enjoying this bloody milkie too much. Oh I see there’s a twitter account as well .. cool .. @Steri_Stumpie.

You know what life is good, who needs the Land of Milk and Honey? SA is the land of MILK, that’s good enough for me.

Now my only worry is to remember to get a new case before I run out!! Erk.

Advertisements

A bit on RESTful webservices

February 10, 2009

Today I was put on the spot and asked to explain REST as it pertains to Web Services, unfortunately I found that I could not articulate that which I know and ended up basically flubbing the opportunity. Uggh, I was so angry at myself.

The truth is that REST is not easy to use and/or explain. Yeah, its simple but its not easy, in fact its hard. So I thought to avoid that particularly uncomfortable situation recurring that I should come up with some basic points to explain it, I shall call them Conrad’s 4 basic cornerstones of RESTful Web Services. Those reading here should also see it as an opportunity to chime in and help by providing feedback as I think there are a lot of people that THINK they understand REST but don’t really grok and I am certainly not excluded in that statement. I am not going to go into the benefits and what not, read wikipedia for that. This is purely some notes on the very basic principles.

Conrad’s 4 Cornerstones of RESTful Web Services (HTTP)

REST = Representational State Transfer

  1. The service exposes application state and interaction as resources that can be represented (sic) as a unique URI over HTTP
  2. Resources are manipulated (maybe not the right word) through a uniform interface, these are POST, GET, PUT and DELETE verbs
  3. The service is stateless.
  4. The service is strictly client-server

Right I believe that is enough for my purposes, there are some other bits around Caching and Layering, mime types and response codes that my points don’t cover but IMHO we are ok as HTTP takes care of that for us to some extend and the rest are less crucial to grokking the concept and thus removed for simplicity.  (opinions?)

What does the URI address for the resource look like?
A simple example:
http://mysite.com/api/user/1
Here we are addressing a specific resource in the user collection .. though we are not expressing any intent as we are not providing a verb.

Throw a verb in the mix:
GET http://mysite.com/api/user/1
Ah, now we are getting somewhere we want to retrieve the data for that specific resource.

OR

DELETE http://mysite.com/api/user/1
I would like to delete the addressed resource..

Similarly POST would create a new user (drop the resource identifier “1” here) and PUT would alter and replace the resource.

Thus the verbs loosly map as follows for out purposes:
POST = CREATE
GET = READ
PUT = UPDATE
DELETE = DELETE

Responses on these actions will return status codes, another handy HTTP freeby that REST can use e.g. 200 OK’s and 404 Not Found etc..

To state or not to state?

Um REST is stateless and the so-called gray area of using cookies for auth purposes is not gray, its broken. Just deal with the fact that your are not 100% compliant and leave that there.  Alternatively look at Amazons Rest Auth implementation which operates via headers sent to and fro. Also adding the session identifier to every URL is not valid as this breaks the uniqueness of the resources’ address as each user will utilise a different URI to address THE SAME resource!

Ok I am tired now, I still want to talk about using RESTlike URL’s in your web application/site (as opposed to API’s for webservices) as I have done in the past which raises issues such as the difficulties of using PUT and DELETE via browser forms often addressed by repurposing the POST method somewhat .. maybe subject matter for a next time.

PS whats up with Facebooks so-called RESTlike API?

Methods like admin.getAllocation etc??? Looks more like RPCLike what with method names getting sent in the requests? Use of HTTP and XML does not a REST service make!

Jack’s Back!

February 3, 2009

Well for the umpteenth time anyhow. No this is just a note that I will be attempting to post on here again, after the tumblr blog turned out to be a horrible failure, apart from the twitter feed integration. But I may feel the need to write something proper from time to time again …