Solve API problems fast with Runscope. Learn More →

JSON Generator: Create Random, Structured JSON Mock Data with Finesse

By Neil Mansilla on .

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 (, 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.


Catch Runscope at AWS re:Invent 2014

By Neil Mansilla on .

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



Build a Health Check API for Services Underneath Your API

By Neil Mansilla on .

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

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 ( and bound to the default port (3306).

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

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

  if ($link->connect_errno) {
    echo('{ "status": "Unable to connect" }');
  else {
    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.

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.

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.

Categories: api, code samples

Add Runscope Logging to Your ASP.NET Web API in minutes

By Darrel Miller on .

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


Everything is going to be 200 OK

Sign Up — Free!