{"API Evangelist"}

Messente API: Always Use A Backup DNS Solution

I found the DNS implementation over at the Messente SMS API interesting, and worth of sharing for deeper evaluation. I've been considering the various approaches by API providers when crafting their domains, or subdomains for API access heavily over the last couple weeks.

During some research time today I stumbled across the Messente SMS API which opts to provide two domains for making HTTP(S) requests of their API:

  • api2.messente.com
  • api3.messente.com

Messente provides a little disclaimer to handle the developer side of manual load-balancing these API calls:

These two domains have the same final destination regarding the API functions. In order to ensure that your requests always reach Messente API services, please use one of them as primary and the second one as backup. Both API domains work as equal, but in case of any unexpected downtime with one of them (HTTP 5xx), the other one must be used on client side.

I'm not sure this manual approach to providing API endpoints is the optimal path when delivering on the stability of your API, let alone the location of your resources, but it does provide an interesting contrast on the perspectives that are available out there in API-land.

Sometimes I feel like I should rebrand as API Anthropologist, as I find the approach of my fellow API providers more interesting than what I'd expect to find in a mature API landscape. This reflects the importance of showcasing what is going on, to help bridge to where we should be, rather than focusing exclusively on where we should be. (deep shit, man)

Guest Post: Help Us Bring Out The Worst Of The Net So We Can Generate Page Views

This is a guest post from one of our sponsors. We actually cringed, and puked in our mouth a little bit when we saw an email come in from this company, requesting a post, but they paid us well, and we knew the topic would generate an insane amount of page views, so what the hell—we can drink more so we can sleep at night.

Our company didn't actually write this post, we just grabbed it from a blog that we regularly read, written by someone who actually understands the topic. This approach is much more beneficial to us, as we don't actually have to have any creativity, or skill, and it doesn't cost us a dime! #winning

When we found this post, it had an informative title, but for the purposes of this guest post we changed the title a little bit, in an effort to make it more desirable, clickable, and shareable by our readers. 

This post also had a lot more context when we found it, but for the purposes of this guest post we are going to remove most of that context. We also want to make sure and not cite the author, and potentially provide any unnecessary background--well maybe a Twitter account so people can spew venom at them. All of this goes along way in making sure the article invokes the passion we are looking to generate, which will result in the volume of traffic we desire.

Once this is posted, we will syndicate to the places on the Internet where the worst people you can imagine dwell. This is the tech industry, so there are some pretty proven places to go to find these types of folks. These people don’t represent the entire Internet, but because they are so outspoken, you'd think they do. All we have to do is post a link, artificially pump up the first few votes, and the community does the rest. #magic

We just want to encourage a ‘conversation". We don't care if people are actually represented fairly, that any critical context is missing, or people might not be safe—we just want the page views. Thank you for joining us to bring out the worst of the Internet, and ensuring a very vocal minority continues to have a platform to spread the worst aspects of our society.

This is the beauty of the Internet and advertising models, is that we get paid to continue making the Internet a total cesspool. #thankyou

P.S. Normally this type of story would be on Alternate Kin Lane, but I paid myself so much money I was able to buy a slot here on API Evangelist.

API Sandbox And Simulator From Carvoyant

I’m digging deeper into my Evernote lately, getting back to those half written stories I have laying around, and next up is about the Carvoyant API sandbox and simulator. I came across their Free #connectedcar data candy in the Sandbox blog post, and was intrigued by the concept of a simulator, not just for IoT related APIs, but potentially for any API.

Carvoyant provides a free API account which comes with a sandbox API for playing with the platform, and a traffic simulator that allows you generate vehicle and trip data for use in developing applications. I can see how a sandbox plus simulator is essential for developing automotive related applications, as you can’t be expected to have real car connection and data in all scenarios, something clearly Carvoyant has put a lot of thought, and work into.

Providing an API sandbox plus API simulator seems like it could also be two essential building blocks required for all device based API platforms, aka Internet of Things. This approach would be significant in on boarding new developers, providing them with immediate scenarios they can hack against, to learn about an API, as well as light the fire within their imagination regarding what is possible with the platform's API.

I already have a sandbox as one potential API management building block that API providers should consider. I think I will also add a simulator to the API management building blocks, and keep an eye out for other API simulators in the wild. I know I’ve covered sandbox templates from SaleForce in the past, but usually once I’ve seen something in the wild a couple of times, and add it as a formal building block to track on, I immediately tend see more of it out in the space. Have you seen any cool API simulators?

Some Examples of API Integration Pages In The Wild

One pattern I'm seeing emerge on some of the API platforms I’m watching from week to week are integration pages, showcasing the other 3rd party services than an API has integration with. An integration page is similar to an application showcase, but instead of showing apps build on an API, you are showcasing other platforms that are already integrated with.

A recent one that I’ve seen out in the wild is from web development annotation platform Usersnap, showing the platforms they connect to:

The second I came across was from OpsGenie, the alerts and notification platform, showcasing all of the common platform they work with:

I’m going to add an integrations page to my list of API management building blocks for API providers to consider. An integration page can showcase a wide range of integrations that introduce reciprocity into platform operations. Integrations could start with using Zapier, but could also be seamless, providing plug and play connectors for users. I would say integrations goes right up to what I call platform development kits (PDK), which would be open source code that developers could use to get up and running on 3rd party platforms.

If you don't have any existing integrations to showcase, I recommend spending some time and figure out the top 5 platforms that would complement the value delivered by your API, and get to work integrating. Existing API integrations are great for stimulating the imagination of developers, as well as provide ready to go solutions for non-developers--either way an integrations page will help onboard new API consumers.

Project Idea: Server Side API Deployment Using Open Source API Frameworks

As I write up a story on Magnet, another one of the API SDK service providers to emerge in the space, I can't help but evaluate what other building blocks have the potential to evovolve, and be offered as a specific service. Machine readable API definition formats like Swagger and API Blueprint make services like Apimatic and Magnet possible, and I enjoy thinking about other potential services that could be easily generated from definitions in this way.

One possiblity that comes to mind is server side scaffolding, and the possibilities of generating server side scaffolding for your APIs in a variety open source API frameworks, using machine readable definitions. It is difficult to generate 100% of the server side of an API using machine readable API definitions, but you sure can go a long way in auto generating a scaffolding that will get you most of the way there.

I’m picturing a whole library of every REST framework known to man (and woman), and the ability to select framework, and upload a machine readable Swagger specification, and the service generates a zip file, or publishes to Github for you. The service would save you the time of going out and finding the latest version of your favorite (or clients) REST framework, and do most of the heavy lifting in setting up, configuring, and crafting API endpoints. Eventually you might think about other ways to distribute, like docker containers on AWS, Google, and even PaaS services like Heroku.

It would be easy to use APIs.io, and the APIs.json files to find API design patterns, and make those available in a library alongside all of the available REST frameworks. I would build this myself, but I just don't have time, and it isn’t an idea I think anyone is going to get rich off of, but I think you could make a good living charging a couple bucks to generate server side API scaffolding, and keep tabs on the latest REST API frameworks.

I’ll keep sharing these ideas that are generated from my monitoring of the API space, in hopes some of you take advantage of them, and bring them to life.