Cloud vs On-Premises (local)

Note: Did you receive an Invalid Request message? It’s possible that you are trying to reach an environment that is behind a firewall that our public cloud accounts can’t reach. You may need to whitelist our IPs, or install an on-premises trial. Please contact support@apifortress.com to learn more, or use our chat bot.

The API Fortress platform was uniquely developed to function in our cloud, or from your own virtual private cloud or data center. This was to allow for customers that have security requirements that don’t allow for use of the cloud version (like private staging environments). The entire platform can be deployed behind your own firewall using Docker, Kubernetes or OpenShift.

To trial cloud simply register an account. To trial on-premises please fill out this form and contact sales@apifortress.com to learn more.

Why On-Premises?

There are more details on the on-premises option here, but the main reasons for choosing on-premises over cloud are:

  • On-premises can have access to environments behind firewalls, like staging and preprod.
  • On-premises is unlimited in terms of tests and executions.
  • Load Testing and Mocking are currently only available on-premises.
  • More control over scheduling, database choices, etc…

An on-premises deployment is simple to do. Please contact sales@apifortress.com and we’ll help you get setup.

API Tests vs. Schema Validation

One of the most common questions we receive about API testing is:

What’s the deal? Schema validation was not enough?

Some of these inquiries are moved by real curiosity, others are just polemic, but either cases, the question makes a good point if you’ve never actually tried our platform.

Schema validation has two major flaws:

  1. You need to write a schema
  2. It statically validates your API syntax and grammar, not your data and certainly not your darkest secrets.

For what concerns ( 1 ) deal with it.
( 2 ) is a little more intriguing. Let’s work by example.

{
  "group": "food",
  "items": [ 10,15,17,19 ]
  "install": false,
  "installDay": null
  "delivery": true
  "request_date": 1456249628
}

Of course a schema can determine whether these items are the right types, but no schema can tell that:

  1. Food items should have ids lower than 100
  2. Food items should not be installed (weird, right?)
  3. Food items have no installation day, but they’re deliverable
  4. The response shouldn’t be older than 1 day (caching?)

Moreover, API testing allows you to compare things with the request data. You don’t want to get bathrobes listed while you were looking for your birthday cake. Or, more technically, you don’t want the data within a credit card transaction to be cached.

Right?