When API Documentation Is So Bad that It’s Good, Part 3

Web Method
data.moveData

Description
Apparently, for some of you out there, it was not simply enough that you could just save data as a record with a provided ID. No…that wasn’t enough. Some of you bastards have insisted on moving data from one record to another. Who would need to do such a thing?!? Personally, you make me sick…but since you’re our special client, we have implemented the precious functionality that you need from us.

Request URL
http[s]://ima.weiner.com/carlosdanger/trousers.moveData

Parameters

Required Level Name Type Description
Required SourceID String The ID of the record from which data is being moved.
Required TargetID String The ID of the record to which data is being moved.

And there you go…happy, assholes? Oh, but I forgot…there are a few more additional steps after you call the method…

1.) The return value of this method is a string (which we will refer to as your TrouserKey); you will want to hold onto this for future use.

2.) Since the method is asynchronous, you will need to wait an undetermined amount of time before the data is actually moved. Usually, depending on the weather, this interregnum is somewhere between several minutes and a couple of days. However, you are allowed to occasionally (occasionally!) call our “hasBeenMoved” method, using your TrouserKey to see if the data has been moved yet.

3.) After repeatedly poking us with your TrouserKey and finally getting a Success from the “hasBeenMoved” method, you should get ready to call the “getMovedStatus” method. Since your data is important to us, we do provide two-factor authentication when getting the status of your data. So, at this point, we will wardial your company’s location and send you a fax with a PIN number. (Not to worry…if you don’t own a fax machine, we will send you a FedEx package with the PIN number in it.)

4.) Finally, after receiving your PIN number, you can use your TrouserKey and PIN number to call the “getMovedStatus” method, and then…voilà! We will return a formatted URL with embedded JSON in it…which, when you think about it as a smart person, makes sense. It will look something like this:

http[s]://ima.weiner.com/carlosdanger/trousers?TrouserKey=3fb39e4390f0&statusrequest=%7b%22WhoIsFat%22%3a%22YoMomma%22%2C%22
WhatShouldIRead%22%3a%22BlowingTheBridge%22%7d

I don’t often say this…but that’s just beautiful, plain and simple. And it totally makes sense to do it that way. Totally.

5.) After calling the URL, we will return a simple text page that will have either a “Success” or “Failure” in big, bold letters. If you wish to know the reason for the failure, you’ll need to call our support number and be ready to communicate in Swahili.

It’s that easy! And if you don’t like it…? Go suck it! I ain’t breakin’ my back for you, asshat.

Peter Bolton is the author of Blowing the Bridge: A Software Story and has also been known to be a grumpy bastard on occasion.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s