We've teamed up with James Higginbotham of LaunchAny and Keith Casey of Casey Software to bring you their hand-curated weekly newsletter for API developers. You can subscribe to the API Developer Weekly email newsletter here. 

Also, be sure to check out James's and Keith's new book A Practical Approach to API Design on Leanpub. On to the links!

Hot Topics

What we can learn from the Yo API

"We started Yo’ed, a hub entirely written with Golang, which triggers actions when someone Yo’ed an account. While playing around with the API, we also wondered why we were attracted to it in the first place. Having a closer look, we discovered that it has great lessons to teach us!"

API Changelog Aims to Reduce Risk to API Consumer Business Models

"API Changelog provides up-to-the-minute tracking of APIs to ensure that API developer-consumers are alerted to any upgrades or changes to endpoints. Changes to an API can create business risks as the end customer’s experience may be affected if an API being used in an application or aggregation product suddenly becomes inaccessible."

Microsoft Tackles Internet-of-Things With New Data Stream Processing Service

"Microsoft added Event Hubs to its portfolio of messaging services called the Azure Service Bus. Event Hubs  is similar to Service Bus Queues and Topics in that it supports first-in-first-out messaging, competing consumer scenarios, and data retention policies. Its client-side cursor, partitioned consumer support, and significant time-based retention options are unique with the Microsoft portfolio."

An API Definition As The Truth In The API Contract

How the API definition, terms of service, and other aspects of an API combine to create a complete API contract and how a machine readable version of this contract is important to provide assurances to API consumers. 

Slideshare: Reusable APIs

Mike Amundsen's recent presentation on how to build APIs that are reusable and more machine readable. 

Facebook fixes huge API security vulnerability

"Security researcher Stephen Sclafani discovered a massive API-based security vulnerability at Facebook. Facebook's security mistake is one from which all API developers can learn. Most Facebook users were vulnerable to spying, spamming and hacking because of lax security on an old API."

The Business of APIs

The Benefits Of APIs For Transport And Logistics

A look at the recent API momentum in the transportation and logistics sector.

The Real World Cup Winner: APIs

"What was really interesting was how this was truly a, “World Cup powered by APIs.” World Cup organizer FIFA has stated that more than a billion fans worldwide accessed information about the tournament through its digital platforms."

To fight Google and Foursquare, Yelp frees its data

"Get ready to see Yelp reviews all over the web. The local business discovery and review site recently announced a revamped API, which increases the number of calls a third-party app can make to Yelp’s data to 25,000 calls per day, compared to an earlier 100 call limit."

API Development

Hypermedia as the engine of application state, the client-server dance

"We are currently seeing a significant amount of discussion about building hypermedia APIs.  However, the server side only plays part of the role in a hypermedia driven system.  To take full advantage of the benefits of hypermedia, the client must allow the server to take the lead and drive the state of the client.  As I like to say, it takes two to Tango."

Video: Adrian Cockcroft: Migrating to Microservices

A video presentation from Adrian Cockcroft on the strategies, patterns and pathways to perform a gradual migration from monolithic applications towards cloud-based REST microservices.

Create and Host your First Web API with APISpark

A look at the APISpark platform and how to build your first web API in 15 minutes or less.

CORS Makes Your API Portable And Remix-able

"CORS being enabled, is the difference between an API being portable, and remix-able, and it being locked down to its original developer portal."

Cloud Watch (from Cloud Developer Weekly Newsletter)

Amazon's Cloud Is One of the Fastest-Growing Software Businesses in History

"Five billion dollars. That’s how much Amazon.com (AMZN) will rake in from its cloud computing business this year, according to a new estimate from Pacific Crest Securities. If true, it’s an incredible figure. It would mean that Amazon’s cloud revenue shot up 58 percent in a single year, from $3.1 billion in 2013."

Rackspace, battling Amazon, tiers cloud services to show off its strengths

"Facing off against cloud giants AWS, Microsoft and Google, Rackspace regroups in a way it hopes will show off its service and support advantages."

10 Docker Tips and Tricks

"As a Solutions Engineer at Docker Inc., I’ve been able to accumulate all sorts of good Docker tips and tricks.  The sheer quantity of information available in the community is pretty overwhelming, and there are a lot of good tips and tricks that can make your workflow easier (or provide a little fun) which you could easily miss."

When do bash init scripts run?

A nice diagram posted to Twitter show when various bash init scripts run. 

Recommended Security Setup for AWS

"While we’ve never heard of a security breach inside of AWS itself, there have been numerous incidents of Amazon accounts getting illegally accessed and damaged. When thinking about application and hosting security, it’s important to frame the questions in the right light. Specifically, always use the word when."

Why a Media Giant Sold Its Data Center and Headed to the Cloud

"Condé Nast's CTO says the media company is no longer in the business of maintaining a data center. It has gone 'all-in' on the cloud with Amazon Web Services."

Want to share something?

As always, if you want to chat, share a link, or make a suggestion, feel free to drop us a quick note using Twitter (@launchany and @caseysoftware) or by emailing us at: james@launchany.com.

The agenda.

Earlier this week I headed to Detroit for the second annual API Craft Conference. Being my first time I didn't know what to expect, but I knew many of my fellow API design aficionados would be on hand and I was eager to learn from the many smart attendees.

Day One: Hypermedia in Focus

This year's API craft started with a Hypermedia Panel. The creators of all the most popular hypermedia formats were on the panel and they all had an opportunity to do a short presentation. The event was streamed and recorded.

One of the most important takeaways for me from this panel, was that there is a growing appreciation for the fact that hypermedia is more than just defining passive relations between resources.  Abstracting behavior behind hypermedia links is an equally valuable scenario.

Days Two and Three: More than Just Hypermedia

As an open spaces conference, the second day started with people pitching ideas for sessions. I was particularly interested in the sessions relating to ways of communicating semantic meaning because I believe that is one of the biggest remaining challenges in API design. Some clear themes emerged from the session proposals: testing, measuring, monitoring and managing of APIs was well represented, as well as plenty of sessions around making the business case for APIs and especially hypermedia APIs.

The rest of the day was jam packed with valuable sessions and conversation. I learned about the variety of different ways people map their domain to resource models in Glenn Block's session on Web API architectures. In the API testing session run by Kevin Shamoun it was interesting to hear the tools developers were using and the challenges they were facing.  Kevin Swiber held a very well-attended session, amusingly named 'Why y'all hatin' on hypermedia?' where we discussed commonly heard objections to hypermedia and solutions to overcome those objections. 

During the closing discussion, I asked the attendees how many were already working on hypermedia based solutions, and I would estimate between 30-40% of hands went up.  This is a huge increase from what I have seen in the past.

Despite the abundance of hypermedia content, there was plenty of discussion on topics like security, testing, monitoring, management, design, diagramming, mobile, IoT, and many more topics.  The proceedings for all the sessions are being recorded in the Github wiki. 

Overall, my three big takeaways from the event were:

• Hypermedia is finally getting mainstream attention.
• The level of expertise in HTTP API design is significantly improved from a few years ago.
• There continues to be a big demand for HTTP API related libraries and tooling, especially on the client side.

API Craft was a great conference and I'll definitely be reserving the dates on the calendar when next year's event is scheduled.

API authentication schemes come in all shapes and sizes. Tokens, HTTP basic auth and OAuth are the most common that our customers use. Different versions of OAuth present different challenges though, with OAuth 1.0a being the most complicated of them all.

Today we're launching native support for OAuth 1.0a in your Runscope API tests. No more complicated scripts or request signing steps, just enter your keys and run your tests.

Simplifying Signatures

If you're unfamiliar with OAuth 1.0a, let's recap how it works. Every request you make to a protected resource on an API that uses OAuth 1.0a needs to be signed using a shared secret that only you and the API provider know, specific to your app. Request signing is a complicated, error-prone process; thankfully made easier by the plethora of libraries for various languages.

When testing or monitoring APIs with Runscope, these signatures were especially hard to generate. Now, paste in your credentials and the request signature will be automatically generated and added to the request:

As you can see in this example, Variables are fully-supported so you can store your keys once for a specific test or all tests within the same bucket.

If your API developer portal doesn't generate keys for you to test with, the Runscope OAuth 1.0a Token Generator can help you out.

More to Come

We'll continue to improve support for different authentication schemes, including looking into ways to address the UI-driven portion of OAuth 1.0a or 2 authorization flows. Help us out by letting us know what your API authentication requirements are.

Every team works with their APIs a little differently. Because of the variety of environments our customers have, it's important that we provide flexible extensibility options to make sure we allow developers to build integrations we may not be able to build ourselves. We offer three main ways to do that: the Runscope API, Radar webhook callbacks, and Radar Trigger URLs.

Over the past few months we've been improving these extensibility points based on your input and feedback. The backlog of undocumented features was getting a little long, so we've documented them all and have summarized the changes below (with a bonus Passageway feature).

Radar: Test Results API

We've added additional endpoints to the Runscope API (for interacting with your Runscope account data) for Radar tests and results. You can use this API to build your own test status dashboards or integrate with other services that don't accept webhooks. 

Learn more →

Radar: Trigger URL for All Tests in Bucket

We've added a Trigger URL that will queue a test run for all tests within a bucket. This is similar to the "Run All" button on the Radar test overview page. Bucket-Wide Trigger URLs support custom variables and can be found in the Bucket-wide Settings.

Learn more →

Radar: Batch Trigger URL

Sometimes you want to run a single test with multiple sets of initial variables in one go. The Batch Trigger URL supports just that, allowing you to start up to 50 test runs for a single test at once, each with a unique set of initial variables. 

Learn more →

Radar: Additional Trigger URL Response Data

All Trigger URLs have been updated to use a new response format that will detail the one or more runs that were initiated, including the resolved initial variables (the variable state after bucket-wide and test-specific initial variables and scripts have been processed). The response also includes the agent ID or region code that will execute the test run.

The new response is returned when using a Trigger URL ending in /trigger, bucket-wide Trigger URLs, or the Batch Trigger URL. For backwards compatibility, Trigger URLs using the previous format (URLs ending in /start or /run) will continue to function indefinitely. We recommend migrating to the latest version at your earliest convenience.

Learn more →

Radar: New Trigger URL Options for Locations

Two new parameters are now supported for choosing which locations to use for the test runs initiated by the Trigger URL. You can specify one more more runscope_region parameters to initiate test runs is specific geographic locations. If you're running the Radar agent in your infrastructure, you can specify one or more runscope_agent parameters to start a test run using the specific agents.

Learn more →

Radar: Additional Webhook Notification Payload Information

The payload delivered for webhook notifications has been updated to include the location (region or agent) the test run was executed in, more details about the requests executed (including response time, size and status), and the initial variable state before the first request was executed.

Learn more →

Radar: New Data Sent to New Relic Insights and Keen IO Integrations

Location (region or agent) for a test run is now included in the test run event data sent to New Relic Insights and Keen IO.

Radar: New Built-in Function

A new built-in function to generate a random string of up to 1000 characters is now available. Use {{random_string(10)}} (replacing 10 with your desired length) to use the new function in your request templates.

Radar: New Script Functions for URL-safe Base64 Encoding/Decoding

Radar Scripts can now use atob(input) and btoa(input) to do a URL-safe Base64 encoding or decoding of a string. This mirrors the functionality of window.atob() and window.btoa() in browsers.

API: Delete Bucket

The API now supports deleting buckets (except the default bucket on an account) by key.

API: Share Request

A new endpoint has been added to support creating a public share URL (similar to sharing a request in the dashboard) for a given message.

Passageway: Predictable URLs

Passageway generates a unique tunnel URL on each initialization of the agent. This can be annoying if you're using Passageway as part of a CI process. Using the new --fixed command line flag you can get a consistent URL between runs of the agent.

Keep up With the Latest Updates

Be sure to follow @Runscope and keep your eye on the Changelog for all the latest product updates new features.

Every day we hear from Runscope customers who are looking to run the same Radar test against multiple environments. Sometimes it's "staging" and "production" environments, other times it's for a fleet of servers behind a load balancer that all serve the same API.

In this post I'll show you how to use a few of Radar's features in order to create a single test plan that can be applied to different environments.

Creating the Test Plan

Let's start by creating a simple test plan using the Runscope API. In this case we'll just hit a set of endpoints in our 'prod' environment directly:

This is a simple test that checks that our credentials are correct, creates a new bucket, then retrieves the newly-created bucket (the second request stores the new bucket key in a variable if you were curious).

You can see that all of the requests are hard-coded to use our production host name in the URL. We also have an "Authorization" header (not shown) with a access token that will only work in our production environment. To make this test work with our staging environment we need to start by abstracting out the environment-specific data into variables.

Using Initial Variables for Environment-specific Settings

I'll define two Initial Variables for our baseUrl and accessToken values, using the same values I previously hardcoded into the request editor.

I've included the the scheme in our baseUrl value since our staging environment uses plain http instead of https. I also left out the trailing slash since it makes tests easier to read later on when we use that variable.

With our initial variables defined, update the requests to use the variables:

When I run the test from the dashboard, it will use the values I've entered in the Initial Variable editor and dynamically insert them into the requests:

With our test plan defined, we can now use Trigger URLs to initiate test runs with custom sets of initial variables.

Dynamically Specifying Environment Variables with a Trigger URL

Trigger URLs let you kick off test runs from other tools that are part of your build or deploy process, like GitHub, Jenkins, Heroku and more. Every test has a unique Trigger URL that accepts a single GET or POST request to start a test run. These URLs also accept parameters to allow you to specify custom initial variables to use for a given test run.

For this test, I've put together a Trigger URL that sets the baseUrl and accessToken values to match those required by our staging environment. It looks like this:

https://api.runscope.com/radar/b6e82b82/trigger?baseUrl=http%3A%2F%2Fstaging.example.com&accessToken=testtoken

Requesting that URL via curl or the browser will start a new test run with those values, overriding the default values and dynamically inserting them into the request data:

For our case, we make a request to the Trigger URL at the completion of a deploy for a service to any given environment. We can also run these tests against local or private endpoints using the Runscope Radar agent (in private beta, contact us to learn more).

Need help with your own API tests?

If you need help getting your API tests configured to run in multiple environments, drop us a note, we're standing by ready to help.

APIs live in a lot of different environments. One consistent story we've heard from customers is how many private or internal APIs they have that exist solely behind a firewall. We've been working hard to make it possible to use Runscope Radar API monitoring and testing in these situations:

• Accessing APIs that exist solely behind a firewall without exposure to the public internet.
• Running tests against a development version only running on localhost.
• Monitoring APIs that require a known or fixed IP address (aka IP whitelisting).
• Running your tests from a cloud hosting provider like Microsoft Azure, Digital Ocean, or SoftLayer or in a geographic region not currently covered by a Runscope Service Region.

In each of these cases you need the flexibility to determine which environment your API tests and monitors are run from, without losing the powerful test editor, team access, 3rd-party integrations, notifications and scripting capabilities you've come to expect from Runscope Radar.

Today we're announcing the general availability of the Runscope Radar On-premises Agent for all Team, Business and Enterprise customers. The Radar agent uses a hybrid on-premises approach keeping your test management in the cloud, but executing the requests in the location that makes the most sense for your infrastructure.

Hybrid On-premises API Monitoring and Testing

The agent is a single executable that can be downloaded and installed on a Linux, Windows or OS X host within your infrastructure. All agent communication with the Runscope API is made via standard HTTPS requests, minimizing the amount of firewall configuration needed to only allowing outbound requests on port 443.

Once installed and configured, the agent will show up as a location in the test editor along side the global cloud-based locations we support (screenshot condensed for brevity, we currently support eight global locations):

When a test run starts, the agent picks up the next request to be executed, makes the request and sends the response data back to the Runscope cloud to be processed. Anything the agent can "see" can now be tested and monitored just like the cloud-based tests!

Getting Started

Use of the agent previously required a Runscope Enterprise subscription but due to customer demand we've opened it up to customers on Team and Business plans as well. If you have a Free or Starter account, you can upgrade your subscription here.

The agent is also available to customers during the free 30-day trial, so if you haven't yet signed up for Runscope, get started now to try out the agent for yourself. If you're on the free plan, you can do a one-time restart of your trial here.

Once you're on a qualifying plan, head over to the agent docs page to download the agent for your operating system and follow the simple configuration instructions. If you need any assistance getting up and running, our support team is standing by ready to help.

Some of your most popular feature requests have been for reporting and analytics -- specifically performance (latency) and usage (consumption) metrics. Today, we're announcing the release of Runscope Metrics for all customers. The first two Runscope Metrics reports that we're releasing are Performance and Usage.

Performance Reports

Runscope Radar is very useful for testing if an API is operating properly. You may have noticed that while defining tests, an assertion for "Response Time (ms)" is an option. True, that catching a failing test is important (i.e. not responding within time threshold), but tracking performance data on successful tests is just as important.

Performance report view, showing increasing API request latency over the course of two days.

Gradual increases in latency (response time) can be signs of a backend service that is not scaling well. Spikes of latency can be an indication of intermittent network problems that are unrelated to the health of the backend service.  Both of these cases are common and mostly go undetected. 

These spikes and gradual increases in latency are now easily spotted with visual performance graphs. By catching latency issues early, developers can investigate and address them before they grow into major problems.

Usage Reports

Keeping tabs on the number of API requests an app makes is also important. Modern APIs implement rate limits and throttles — for example, restricting apps to X calls per hour, or Y calls per day. In most cases, an app that exceeds a limit is denied access which could lead to application failure. It's unfortunate, but that's usually what it takes for developers to discover their API request capacity problem.

Usage report view, showing an irregular spike in API call volume on the morning of Sep 7.

Using Runscope Metrics, developers can stay several steps ahead by monitoring their usage. All API calls that proxy through Runscope get logged. Similar to the latency performance report, the usage report makes it easy for developers to spot both gradual trends in growth as well as spikes. This report helps developers to forecast usage trends and plan accordingly.

Drilling Down to the Method Level

The default reporting view for both Performance and Usage Reports is across all hosts. Finding the exact method that is experiencing latency issues, or ramping up on API call consumption, is very easy. Developers can refine the scope of each report by simply clicking a hostname from the list. From the hostname view, drilling down to the endpoint path and method is done exactly the same way.

Runscope Metrics is available to all customers. If you need help understanding Runscope Metrics reports, send us a note. Our support team is standing by, ready to help.

The following is a guest post from Adeel Ali from APIMATIC, a company that offers an automatic SDK generator for REST APIs. APIMATIC can import schemas/descriptions of RESTful APIs (WADL, Swagger, I/O Docs, API BluePrint, Google Discovery) and generate SDKs (Android, Windows, iOS, Java, PHP, Python, Ruby, Node.js). Adeel shares an easy to follow guide to building an SDK with APIMATIC and integrating Runscope.

Toward Better SDKs - With APIMatic

SDKs or client libraries are an argumentative topic in the API ecosystem. They are rightly criticized being expensive to build as well as painful to update and maintain. On the other hand, they are considered as crucial, which is evident from the fact that almost all of the top APIs come with SDKs. A closer look at the SDK criticism reveals that the actual pain-point lies in the current development lifecycle of SDKs, and it’s no brainer that if SDK development can be made efficient then it will be a win-win for everyone.

A solution to the above pain-point is replacing the problematic manual development of SDKs by automatic SDK generation. Auto-generated SDKs are cost-effective, easy to update, and offer huge reduction in work-load. APIMatic.io is an automatic SDK generator, based in the land of Hobbits with the exact vision of better SDKs. APIMatic was founded in May 2014 by me and Zeeshan, and currently is in public beta phase, that means you can get SDKs for your API in 7 languages for FREE. More about APIMatic can be read in a review by Kin Lane. 

APIMatic & Runscope – A Natural Alliance

We met John Sheehan for the first time last week at APIWorld 2014, where he hinted about embedding Runscope’s API monitoring capabilities in APIMatic SDKs. The idea looked very intuitive because APIs are mostly accessed via SDKs, and by using Runscope powered SDKs, API providers could inspect/debug all of the request and response data traveling back and forth from the clients using their SDKs. The amount of convenience could be assessed by the fact that setting a single flag would automatically enable API debugging capability in SDKs in 7 languages (to date), while no settings would be required at the client side.

The idea has now become a reality, and in the remaining of the post I am going to show how you can generate Runscope powered SDKs.

Runscope Powered SDKs – Step by Step

Step 1
Create a Runscope bucket, and copy the bucket key. 

Step 2
Specify an API description at APIMatic. The two ways to do it are: importing an API description, or describing an API from scratch. I am describing Vimeo’s public API from scratch here, and will only be specifying two end-points to keep the demo simple. 

Step 3
Go to CodeGen Settings and enter the obtained Bucket Key from Runscope. Save the settings.

Step 4
Once the API is defined, go back to the API list, and click the validate button to validate the API description.

Step 5
If all is well, you will be presented with icons of different languages to generate SDKs. Choose your favourite language, and click the icon to download the SDK in a ZIP file.

Step 6
Unzip the contents of the downloaded SDK and open the Configuration file to provide your credentials to access the API. The contents of a generated C# Portable Class Library can be seen in the following snippet. It can be noticed in the Configuartion.cs file that the BaseUri has been transformed to the Runscope-desired format. If you are not using an interpreted language, you’ll now need to compile the SDK to get a compiled binary. There is a ReadMe file in the root folder file if you need any assistance.

Step 7
Now you have a (compiled) library in your hands which you can reference in an application. Here I am referencing and using the .dll file obtained from the previous step in a simple application. This application searches for videos on Vimeo against a provided keyword, and shows the total number of videos found as the result. The code to access the API functions via SDK can be seen in the snippet below.

Step 8
Go back to the Runscope portal, and select your bucket from the top left corner. You can watch all of the API traffic initiated by your app. The summary of the API calls originated by my application can be seen in the following snippet. Click on any particular call to see a detailed record, compare requests or responses, or play around with the other available options at a very friendly portal.

That’s it!

Congratulations on generating your first Runscope powered SDK. I love hearing feedback, so please comment on the post, or send me an email. If you need any assistance, don’t hesitate to ask. 

REST is a topic that always stirs up spirited conversations and ideas. Runscope Developer Advocate, Darrel Miller, recaps his experience at the 5th annual REST Fest in Greenville, South Carolina, an event where the hearts and minds of REST converge, unconference style.

Last week was REST Fest week.  REST Fest is an unusual little conference that happens in Greenville, South Carolina every September.  This is the fifth year it has run and this is my fourth time attending, and I learn a ton every time.

What makes REST Fest unique is its “everyone speaks” policy.  Although there is a keynote, a whole hack day and a number of regular length talks, the bulk of the conference time is made up of 5 minute lightning talks presented by attendees.

Read the rest of Darrel's post...

The other week, while Darrel was discussing hypermedia over moonshine at RESTFest, John and I headed out to Chicago for the API Strategy & Practice conference. This was the fourth APIStrat since it's inaugural event in New York (Feb 2013), and for many in the API space it’s growing into a crowd favorite. APIStrat is organized by API management company 3Scale and API evangelist, Kin Lane.

There were three tracks at APIStrat: providers, developers and industry verticals. The tracks were jam-packed with experienced speakers and relevant topics (both a blessing and a curse). The conference center at the Hyatt Regency was large enough to be comfortable amongst the 400+ attendees, but small enough so that quickly jumping between tracks was easy. I attended several keynotes and stuck to the providers and developers tracks.

The Hierarchy of Developer Needs

Julia Ferraioli, Senior Developer Advocate at Google, opened up APIStrat with her keynote (video) about developer needs. She spoke not only as a developer advocate for a platform company, but as a hardcore developer. Companies that are trying to build APIs that appeal to developers or improve the DX (developer experience) of their platform could spend years getting it wrong, ignoring the needs of developers. Julia’s shared her thoughtful and pragmatic approach to understanding what developers are really looking for in a platform. (spoiler: the hierarchy is dynamic)

Discovering New APIs: Developer Track and the Speed Hack

Sometimes, the best way to learn how to use an API doesn’t involve reading docs or pounding on your keyboard. Instead, it's best to let a developer evangelist hop on their computer and let them take you for a scenic test drive (a live demo). On the day one developer track, I hopped in the passenger seat, and did just that.

Esri was first on stage and introduced us to the ArcGIS APIs. Their platform goes way beyond the surface of plotting points and map tiles -- in fact, a large amount of their data is about what's underground! Next was Steve Marx, dev advocate at Dropbox who gave us speedy demo of their APIs. Watching API calls (file creation and deletion) trigger client side notifications on his Mac was nifty. Amber Feng, product engineering lead from Stripe, shared the story behind their very well-designed Stripe API. If you haven’t experienced Stripe’s developer portal and docs, I highly recommend it.

The Speed Hack was a mashup of a time-compressed hackathon (just 4 hours) and a puzzle-solving scavenger hunt. A handful of event sponsors crafted code challenges, that should have taken about 15 minutes each to complete. Competing teams raced to solve them and earned points. However, it just wasn't code that earned points — other challenges included composing and reciting an API poem, dressing up in a silly costume, or having the most creative team name. For a mini-event that took place within a conference it drew a large and energetic crowd.

John Sheehan (Runscope), Jason Harmon (PayPal) and Steve Marx (Dropbox), playing the tech news trivia game for the Traffic & Weather podcast.

Traffic and Weather

Steve (Dropbox) and John (Runscope) host a semi-regular podcast discussing the latest in APIs called Traffic and Weather. They broadcasted a special live podcast during APIStrat, in a format that paid homage to NPR’s Wait Wait… Don’t Tell Me radio news quiz. Complete with tech news headline fill-in-the-blank, API limericks, and heaps of shenanigans, Traffic and Weather was a huge hit, full with many unsolicited (and solicited) applauses. Winning contestants won either Steve Marx’s voice on their voice mail greeting or a bottle of water. Most opted for the latter. Want to watch it? Click here.

"Test Locally, Monitor Globally"

On day two, John gave a talk in the API Testing track. He discussed the importance of logging, monitoring and measuring API usage, and tactical advice on doing it effectively. Nothing beats a (working) live demo, and he pleased the crowd with some local environment API testing through the Runscope Radar Agent, as well as testing on an internet-based API from multiple locations around the world.

Jerry Yoakum (Expedia Affiliate Network API) and Emmelyn Wang (uShip API), both fantastic Runscope users, enjoying some IPAs post API conference.

Wrap Up

Indeed, “API” is a buzzword du jour, so beware of any event who’s name bears it. However, the API Strategy & Practice conference is an event worthy of putting on your calendar. It attracts a lot of players from the API economy — developers, architects, and product owners from the provider side, as well as developers and integrators from the consumption side. A key benefit of APIs is how they enable businesses and people to more easily connect. APIStrat embodied that spirit well, with great content up on stage and amazing discussions between sessions. We're looking forward to the next APIStrat!

Last week, Xamarin held their Evolve conference that centered around cross-platform mobile development. Runscope developer advocate Darrel Miller attended the conference and gave a fantastic talk titled, "HATEOAS - Hypermedia As The Evader Of App Stores." Read Darrel's recap of his experience at Evolve.

This past week I spent in Atlanta, Georgia, attending Xamarin Evolve and Atlanta Code Camp.  This was the second annual Evolve conference and attendance went from 600 the first year to 1200 this year.  This year’s event was an impressive affair.

Cultivating an Niche

Not only did the number of attendees grow significantly from last year, there were 700 of those people who attended the pre-conference training sessions.  This is a significant amount of demand for what is perceived by some to be a fairly expensive set of tools to build cross-platform native mobile applications.

As Mike Beverly notes, Xamarin are making the transition from a place where C# .Net developers go to create iOS and Android versions of their applications, to a cross platform solution for developers of all platforms who are prepared to learn C# and .net.

The idea that you can build mobile applications that have the look and feel of the native platform, but share a significant chunk of client code between platforms is a lofty goal.  One that Xamarin seem to be making significant progress towards.

Read the rest of Darrel's post...

At New Relic’s FutureStack conference, Runscope was on the ground as a partner, sponsor and exhibitor. Over one thousand attendees came to Fort Mason in San Francisco to learn about New Relic’s application performance monitoring (APM) and other partner solutions. Runscope had product and engineering team members available to talk shop about API testing, monitoring and engage in friendly games of 4-player Mario Kart. What did we learn after two days of non-stop conversations with developers, hundreds of Runscope live demos and countless laps around Mario Kart Stadium?

Click arrows to scroll photos.

Click arrows to scroll photos.

Developers prefer simplicity: assertions with no coding required

A Runscope feature that developers loved was being able to define test assertions without programming. The most common assertion criteria (i.e. response code, JSON and XML object key values, response size, response time, etc.) and comparison operators can be configured through an intuitive user interface. Scripted (JavaScript) assertions are also available for those that require more advanced logic in their tests.

Click arrows to scroll photos.

Click arrows to scroll photos.

Developers love webhooks

Part of our live demo included the integration with New Relic’s analytics and dashboard tool, Insights. With just two input fields and a click, test data is instantly synced with Insights. By far, the most common followup questions asked were, “What data is being sent to Insights?” and “Can I send the data to our internal data warehouse?” The answers: everything and yes, respectively.

Runscope makes it a snap to integrate with other services like New Relic Insights, PagerDuty, Keen IO, Slack and HipChat; however, pumping Runscope Radar test data into any of your apps can be done using webhooks and the Runscope API. All of the important test result data, such as assertion status, response time (ms), response size (bytes) and more, is included in both webhooks and the API.

Click arrows to scroll photos.

Click arrows to scroll photos.

Kids just aren’t just coding, they’re keynoting

Sporting Google Glass, 12 year old developer Alannah Forster was happy to talk to anyone about her coding skills and projects as she strolled around FutureStack. She even gave us some tips on how to hack on the fancy WiFi conference badges. On day two, she was up on the keynote stage with New Relic CEO, Lew Cirne. Meanwhile, back at the Runscope lounge, 14 year old developer and hackathon veteran David Tesler cleverly customized his title on his digital lanyard.

Overall, we had a great time at FutureStack connecting with hundreds of developers and the next generation of coders. If you’re a New Relic user and want integrate Runscope with Insights, click here to learn how.

Ryan is a Principal Engineer at Runscope. Recently, Ryan was included in the AWS Community Hero Program. The program was created by Amazon Web Services to recognize AWS experts who go above and beyond to share their expertise and knowledge with the greater cloud community. Prior to Runscope, Ryan led technical operations at Pinterest, and before that, at PBworks. I sat down with Ryan and asked him to share a few things about himself and a few Runscope behind-the-scenes facts.

Q: What is your role at Runscope? What are the main types of problems that you focus on?

I'm a member of the software engineering team at Runscope, where I focus on technical operations. "Technical operations" encompasses the work that keeps Runscope up and running: setting up new infrastructure, identifying performance bottlenecks, and building tools to make this work easy and automatic.

Q: How does Runscope use Amazon Web Services?

Runscope runs most of its server infrastructure on Amazon EC2 (although some service regions are powered by other providers). Amazon EC2 is the most comprehensive cloud platform on the market right now, with features like private networking, a strong API, and 9 locations around the world.

We also use Amazon DynamoDB to store data for many of our microservices, and we use Amazon Route 53 to manage our DNS. Route 53's latency-based routing lets us route customer traffic to the nearest service region, which helps us provide a fast experience for all our customers around the world.

As a small (but growing) engineering team, it's been incredibly helpful to be able to rely on a service provider like Amazon to run our low-level infrastructure. As an example, earlier this month we added a service region in Japan. Thanks to Amazon's global presence, it only took us a couple hours of engineering to expand our service to Japan.

Q: Does Runscope use a lot of other cloud services? Which components are managed in-house, and which components are trusted to Runscope's partners?

Yes, we've relied heavily on cloud services for many parts of our infrastructure. For example, we've used Keen IO to power some of the performance and usage analytics in Runscope Metrics. We also use lower-level services like Mandrill to deliver email notifications to our customers.

We believe it's important to focus on our core competency -- API debugging and testing -- and to control our own infrastructure when it's directly relevant to those core competencies. We're happy to rely on our partners to keep everything else up and running.

Have a penchant for DevOps? We're hiring!

Runscope is looking for a DevOps Engineer to plan, build and automate a modern distributed and service-powered infrastructure. To find out more about what it's like to work at Runscope and see other open positions, visit this page.

If you are building an ASP.NET Web API and want a view into the HTTP traffic that is hitting your API then this is a really quick solution that might prove useful.

Add a MessageHandler

In your Web API project, simply add the Nuget package Runscope.HttpMessageHandler and the following line of code in your Web API configuration code:

config.MessageHandlers.Add(new RunscopeApiMessageHandler(<ApiKey>,<BucketKey>);

You can get an API key by creating an Application within Runscope. 

1. Login to your Runscope account
2. Click on your name on the top-right to access your profile
3. Select Applications on the left-side menu
4. Click the Create Application button

You'll find the bucket key from the Traffic Inspector view. It's located at the bottom of the left-side menu.

And you’re done.

Let me show you...

The following screencast demonstrates how to create an ASP.NET Web API, setup a Runscope account and add Runscope logging to your API in less than 5 minutes.

Image Credit : Monitor https://flic.kr/p/4druiD

A running cat, in honor of National Cat Day. That's Oskar (click photo for original). Full attribution below.

Monitoring your API's health and performance is something Runscope can do very well. But what about monitoring the underlying services that your API relies on? Databases, like MySQL and Redis, or DNS services on BIND or Mara -- they don't come with RESTful APIs, and in fact, they communicate over lower-level protocols like TCP and UDP. 

When you're relying on services without monitoring, the only time you realize those services are down is when your API (or the apps that rely on your API) go down. Wouldn't it be great if those services had health check API endpoints?

Creating separate health check API endpoints for all services

One approach is to build simple health check API endpoints — a method similar to a ping that reports whether the service is up or down.  Consider building a health check endpoint for every service your backend relies on and using Runscope for testing, reporting and triggering notifications. If you use the same client library or SDK in the health check app that you use for your API backend, you'll have the additional benefit of dependency testing that client library.

That being said, include as few dependencies as possible, isolating the health check app to only what's necessary to connect to the service. I mean, you wouldn’t want a MySQL test to fail because Redis was down. The health check endpoint should do one thing, and one thing only — check that a single service is up and running. If so, return 200. If not, return 503.

MySQL service check example

Below is a pint-sized PHP sample app to test if a MySQL server is up. This app has no library dependencies. It's using PHP's integrated mysqli library. This app can be parked on any web server that can execute/interpret PHP files (e.g. Apache, Nginx, etc.). Ideally, it would be mapped to an endpoint route specifically for health check resources -- but in this example, I've just placed it in the home directory of a vanilla Apache instance. I have MySQL running on another box located on the local network (10.0.1.150) and bound to the default port (3306).

<?php
  $config = [
     "server"     => “10.0.0.150:3306",
     "username"   => "runscope",
     "password"   => "testpass"
  ];
  header('Content-type: application/json');

  $link = new mysqli($config['server'],$config['username'],$config['password']);

  if ($link->connect_errno) {
    http_response_code(503);
    echo('{ "status": "Unable to connect" }');
  }
  else {
    http_response_code(200);
    echo('{ "status": "Connection successful." }');
  }
?>

Ping! Test the endpoint with Runscope Radar Agent

Since my MySQL and Apache servers are behind the firewall, I'll be testing my new health check endpoint with Runscope Radar Agent. This agent will perform tests on the local network and report the results back to Runscope. The only requirement when using the remote Radar Agent is that the computer can make HTTPS requests. Read more about (and download) the Runscope Radar Agent here. 

After I ran the agent on my local machine (took only a minute to set up), it appeared as a testing location on my Runscope Radar test editor. The location titled Internal-SFO-Office in the screenshot below is my laptop that's running the Runscope Radara Agent.

Runscope Radar Test Editor view. After installing the Runscope Radar Agent on my local machine, it pops up in the list of testing locations.

Next, I clicked Run Now. The MySQL health check test ran from my local Radar Agent. Below were the results from Traffic Inspector.

Response - click image to see the request

Setting up notifications

Viola! The next step would be adding notifications, so that if there is a failure, the correct individual or team could receive email notifications. Additionally, Runscope supports webhooks, so that after tests run, succeed, or fail, Runscope can POST the test result data to any URL. Lastly, if you use PagerDuty, HipChat, Slack, Zapier, etc., Runscope smoothly integrates with all of those services. Read more about notifications here.

Should these be public or private?

You might ask yourself whether these endpoints should be made public or private. The short answer is private. By private, I mean that these should be treated as internal to your company, and not shared with partners or third party consumers of your API. Why? Because the information is too granular and could reveal details about your infrastructure that shouldn't be made public. However, if you were to wrap up all of these micro health checks together, and return a more abstract status response, that would be appropriate as a publicly accessible endpoint.

More micro sample health check apps on GitHub

In addition to the PHP+MySQL sample above, we've built a couple of other examples: Python+Redis, .Net/C#+MS-SQL and Perl+DNS. You're more than welcome to contribute your own. The GitHub repo is located here.

If you need some tips on how to get these health check apps working, or help with setting up Runscope Radar tests against them, our support team is standing by, happy to help.

p.s. I'll be following up with a blog post about a more comprehensive, open source, service health check project that's being worked on here at Runscope.

Cat photo attribution:  LInk to original photo here (Flickr user Tambako). Used under Creative Common license.

Heading to AWS re:Invent in Las Vegas? So are we!

Come by booth #731 to meet the Runscope team. Whether you would like a deep dive into Runscope's features, get your API/DevOps/Cloud questions answered, or just say hello and grab a free t-shirt, we really want to meet you!

Office hours with Runscope team members

The Runscope team will be holding office hours sessions at our booth. Schedule one-on-one meetings with experts on topics such as: microservice architecture, API design, sanity testing APIs, designing tools for developers, technical onboarding, developer outreach, mentoring and more!

Compete in the 200 OK Challenge and win prizes

Put your API debugging skills to the test with this unique contest. Climb your way to the top of the leaderboard by solving increasingly-difficult API puzzles. No coding required, however, coding skills will help. Come by our booth to get started.

Booth location and hours

Our booth is in Hall C (level 2), also known as re:Invent Central, next to registration. Our booth number is 731, beyond the main AWS booth, next to the kiosk photo booth in the center aisle. You can also find us on the mobile app.

Our booth hours are:

• Tuesday - Nov 11 - 5 PM to 7 PM
• Wednesday - Nov 12 - 10:30 AM to 6 PM
• Thursday - Nov 13 - 10:30 AM to 6 PM

Have you ever needed to craft mock data for API or script testing? Creating a single record of semi-realistic structured data isn’t that hard.. but do it at scale, with say, thousands of records can be a daunting task. For instance, I was creating API-driven puzzles for a contest we were running at a tech conference (AWS re:Invent). One of the puzzles required 100+ fictitious personnel records with a sequential index, random guid and fictitious names.

Enter JSON Generator (json-generator.com), a tool that handles the heavy lifting for generating structured JSON objects, stuffed with sequenced and/or controllable random data. Lets dive right in with the example of how I used it for the Runscope challenge question at the conference. 

A Simple Template

JSON Generator has an easy, but powerful templating language. Below is the template I used to generate a roster of 100 random people for the puzzle:

Breaking it down:

• Line 2: roster is the key to our top-level object, which is an array. This isn't a function, it's just what I named the array.

• Line 3: {{repeat(100)}} is an instruction to repeat an array item a number of times. In this case, it's going to repeat the object below 100 times. If we had specified {{repeat(10,50)}},   the array item would be generated somewhere between 10 and 50 times (random number).

• Line 5: {{index(0)}} makes this field an index, and in this case, the starting index number is 0. The next record in the array will be 1, and so on. (integer type)

• Line 6: {{guid()}} generates a random globally unique identifier (string)

• Line 7: {{firstName()}} {{surname()}} generates random first names and last names.

NOTE: The quotes around key names is optional in the template format. In the generated data, required quotes will appear, which is JSON compliant.

Generated Roster

After clicking the Generate button, the JSON object was created based on the template above. Below is a screen shot containing just the first two objects in the array (there were 100 generated):

In this example, I only used four of the many functions that are available on JSON Generator. There are well over a dozen more functions to help you generate structured random JSON objects. A few of my favorites are:

• lorem - random Lorem Ipsum text, configurable by the type units (words, sentences, paragraphs) and the number of units.
• street, city and state - US street, city and state names — and you can choose between full and abbreviated state names.
• floating - floating point numbers (decimals) between min and max values. Various formats available as supported by Numeral.js.
• random - given a set of array values, this function will select one of them at random
• date - given start and end date, will select a random date. Formatting as supported by datef, including ISO-8601. 

It’s not only fun to play with, but it could save you hours of tedious work when you need to generate heaps of mock JSON data. Don’t take my word for it. Give it a whirl. In fact, we liked JSON Generator so much that we decided to sponsor it!

TIP: Save versions of your templates locally as you work.

Back in September, we introduced Runscope Radar Agent, an on-premises testing agent that you download and install on a host within your network. The remote agent appears along side Runscope's global cloud-based testing locations, allowing tests to be executed against APIs behind your firewall, or even those running on the same localhost. Radar Agent has been a huge success, and we're excited to extend the hybrid on-premises deployment model to another key area of Runscope.

Today, we’re announcing the release of the Runscope Gateway Agent. The same gateway software that powers Runscope's cloud infrastructure for making and logging API calls can now be installed on your local network. Deploying the Runscope Gateway Agent within your infrastructure will help to:

• Capture API request and response data made to private or internal APIs that reside behind a firewall
• Troubleshoot and debug those API calls using the Runscope Traffic Inspector
• Increase network performance by keeping API traffic within your infrastructure
• Create Runscope URLs (on your domain name) for services running on localhost
• Access APIs that require a fixed client IP address (IP whitelisting)

How it Works

The agent works by creating a locally-hosted instance of the Runscope Gateway with your own hostname and TLS certificate. Instead of using our cloud-based Runscope Gateways (hosted on *.runscope.net), requests will use the configured hostname for your agent instead.

Inspecting traffic with the Runscope Gateway Agent uses a hybrid on-premises approach. The agent runs on a host within your infrastructure, but traffic data is stored in the Runscope cloud to make searching and collaboration easier. Traffic collected with the agent is available in the Traffic Inspector along with all other traffic made in the same bucket.

All communication from the agent to the Runscope cloud is made securely over outbound requests to the Runscope API via HTTPS on port 443. See Firewall Considerations for more information.

How to Get Started

Use of the Runscope Gateway Agent requires a Trial, Starter, Team, Business or Enterprise subscription. The agent is available for Mac OS X, Windows (64/32-bit) and Linux (64/32-bit). For complete download and implementation instructions, see the Gateway Agent documentation.

Runscope developer advocate Darrel Miller shares a step-by-step instructional blog post on how to integrate AppVeyor (CI tool on Azure) with Runscope to accomplish rock-solid API testing.

Photo by Alex Eylar: https://www.flickr.com/photos/hoyvinmayvin/4906678960/

Fast iterations can be very valuable to the software development process, but make for more time spent doing deployments and testing. Also, more deployments means more opportunities to accidentally introduce breaking changes into your API.

AppVeyor is a cloud based continuous integration server and Runscope enables you to do integration testing of your Web APIs, when these services are combined they can save you time doing the mechanical stuff and ensure your API consumers stay happy.

The following steps show the key points to achieve this integration using AppVeyor, Runscope and Azure websites.

Read the rest of Darrel's post...

Today, in the US, we are celebrating Thanksgiving. On this day, it is customary for people to express what they are grateful for, such as good health, great friends, certain members of the family, on-call support team members, etc. The Runscope team would like to give thanks to our wonderful community of developers, ops engineers and testers for your use and support of Runscope.

We'd also like to announce that as of today, pauses are supported in Runscope Radar tests. Pauses are a new test step that allow you to insert delays between steps in your test plan. You can add as many pauses as you need, with each ranging from 1 to 180 seconds.

A typical scenario for inserting a pause between requests is when request A executes asynchronous tasks with a predictable completion time (e.g. generating a very large report), and request B depends on the completion of request A’s background tasks (e.g. retrieving newly generated report and making assertions). Above, we inserted a 15 second pause between the two requests. Actual pause times may not be exact, but they are guaranteed to be at least the amount of time specified.

For more information, see the Test Steps Editor documentation, or just head over to your Runscope Radar test editor where you’ll find the new Add Pause button. If you need help with pauses, send us a note. Happy Thanksgiving!