How CloudRail Handles the “Seven Deadly Annoyances of API Design”

 In CloudRail

So, there has been an amusing article posted online, which pretty much sums up the reasons why we decided to create CloudRail (and to make it free for everyone to use). It is Eddie Sullivan’s, of Chicken Wing Software, brilliant “Seven Deadly Annoyances of API Design.” You should read it, especially for great lines such as “[…] keeping in view the main goal of an API: to annoy the hell out of developers.”

Although CloudRail can’t do anything with the problems there of the Android system, we do believe that the CloudRail Universal API helps to solve some of the points made there. Such as:

Annoyance the First (and Second) – Trsnss and makingNamesMuchTooLongToBePractical

When you select an API to integrate in the CloudRail workbench, you get to choose the name that your function will use. So, do you actually, for some reason, like names such as “FileUploadToTheUsersChossenFolderInImageFormat”? Sure, why not. Or if you actually do want really abbreviated names (After all, why use FileCreate() when you could just use FC()), you can also do that.

Vexation number three – Using synonyms

One problem with APIs, as the article points out, is that many of them use obtuse names to describe similar processes. As pointed out, how can you tell really what the difference between a “BlankActivity” and an “EmptyActivity” is?

With CloudRail, you get to set your own inputs and outputs for the functions and methods you want to use. This means that you can make the functions as defined or undefined as you want.

Annoyance the Fourth – Poor (or absence of) Documentation

For us, this is one of the biggest advantages of CloudRail.

When using any API, what tends to happen are hours of reading through documentation to try and figure out how an API works. With CloudRail, when the integration is in the work bench, it is simple to add the function you want, and it will work the same way as all of the other functions that you have already integrated into your application.

Annoyance the 5.1beta3 – Version Incompatibility

Yeah, we can’t solve the Android problem of functions working on old versions but new versions. What we can, however, solve is the update process of external APIs. The definitions in the CloudRail universal API are updated as and when the provider does. For example, when Dropbox realised version 2 of their API, it was updated in CloudRail within a day, well ahead of the sunset schedule for version one.

Annoyance the Sixth – Overcomplimification (easy things made hard!)

Yeah, many APIs make things more complicated than they need to be. For example, the Google Docs API makes the simple act of finding and replacing a piece of text incredibly complex.

With the CloudRail Universal SDK, and the ability to select your own outputs and inputs, it is easy to start making sense of the complicated API sprawl.

Annoyance the Seventh – XML

How about being able to choose what you get back when you call an API method? Yep, CloudRail is also a pretty good solution to this problem as well.

All of this points to the problem that we have known for a long while. That the full potential of APIs are not being able to be unleashed by developers due to the complexities and time-sinks of coding for the. With CloudRail, we hope to make this sprawl more manageable and empower developers to make the applications that they have always wanted to make.

Receive our newsletter

  • Get updates about CloudRail
  • Read about new Services
  • Get insights in IoT and Cloud topics

Start using CloudRail today

Recent Posts