Bots, APIs and Automation

Introduction to APIs

Introduction

APIs are normally offered as a library or a module to be used programmatically.

We identify different types of APIs; local, remote, REST, Ajax, Streamed and TCP.

View details »

API Library

Within our framework you'll find the following APIs;

View details »

Documentation

API Documentation, examples, starters, discussions and articles

Our framework is currently built on PHP mostly, but the Bots can be scripted in any shape and form. A lot of the code we generate also ties pretty well with shell scripting.

View details »

Ah yes, back to school my friends, with an entire chapter dedicated to APIs.

Its necessary to review this information, as I believe the general concepts have changed enormously, and are starting to have strange ramifications in most enterprise coding projects at the legal level exceptionally.

Licensing

We are all familiar with Open Source by now. A relatively open license to use and abuse public code. Which is great, it brings transparency to the table and allows to better profile and build secure solutions.

The problem with Open Source as it stands now sums up to which variant you want to use. The GNU general public license is pretty common, allows free distribution and limits the rights to modified redistribution. The BSD license on the other hand grants all rights to use, modify and resale without the requirement to “merge-back” additions.

So basically, if you’re building a solution meant for resell, you need to use BSD licensed code, which can be mixed with your proprietary code.

If you don’t wish to contribute your proprietary code to the public domain, then a GNU licence is counter-indicated for use in your code. At least, the fine print must be analysed and if the included software is to be modified or tightly integrated, then your legal department has to get involved.

And some enterprises decide to forego the entire open source wave and focus on strictly proprietary code. It has its advantages, and its costs obviously.

Myself, I’m just a proponent of get paid to do constructive stuff. :D If you enjoy my code, think about supporting me financially so I can make more code for you to enjoy. And if you hit the jackpot thanks to my code, then please consider giving some decent cashback.

Different API Styles

Enough with pleasantries though, back to our technical dissertation. APIs today come in a range of flavors; your old typical coding library, externally hosted REST APIs (such as a Stock Exchange, Social networks, etc), and internally networked libraries, over RPC, WebSockets or other trivial communication methods.

Some languages, like Erlang, include very interesting programming constructs for working with remote APIs. (But Erlang doesn’t fit very well in our environments, see our previous discussion about PHP.)

Different APIs present different concerns, obviously. A good example are the Social Network APIs which normally have rate limiting capabilities which must be respected by your Bots, for fear of permanent blacklisting your IP. This type of situation has repercussion on the methodology for “timing” the Bot queries as well, which we’ll cover in this book.

APIs and Bots, interactions

But you see how Bots can be “timed” differently, and how their purposes affect their timing requirements. Bots that assist a human doing music would have an entirely type of timing issue, rhythm and cues to follow.

But this book concerns itself with more loosely timed automation mechanisms, more appropriately used within entrepreneurial contexts to automate tasks, file movements, spiders and data gathering.